在上一篇文章《8x Flow 业务建模法（一）：你能分清业务和领域吗？》中，向大家介绍了8x Flow背后的关键思想，即“业务逻辑和领域逻辑”分离，并介绍了业务逻辑和领域逻辑的区别。
从本篇文章开始，我将逐步为大家介绍8x Flow从分析、建模、架构再到实现的具体方法。
原计划这次讲一讲如何基于“合约上下文”进行业务分析和业务逻辑提取，但是因为收到了很多读者的反馈，希望能够更多的讲讲业务逻辑是什么意思，以便更好的“分离业务和领域”。
所以在开始进行业务分析之前，我们需要再来一篇多聊一聊：到底什么是业务？
最近两年，以“事件风暴（Event Storming）”为代表的“领域驱动设计（Domain Driven Design，以下简称DDD）”分析建模方法红遍大江南北。伴随着按照DDD思想指导微服务拆分的流行，“搞微服务必用DDD，用DDD必做事件风暴，写代码必用六边形架构”的做法已几乎成为了某种所谓的“最佳实践”。
虽然我们一边反复强调“DDD不是银弹，事件风暴也不是DDD”，但是还是眼睁睁的看着DDD被用成了银弹，用了事件风暴也被等同于做了DDD。
这两年，我也做了不少DDD的实践和咨询服务，也写过一些文章和组织过DDDChina峰会上的工作坊。但是在持续的解决不同的客户需求的过程中，确实经历了一个从“忽视到真香，再从真香到疑惑”的过程。其中在使用DDD和事件风暴的过程中，经常困惑的一些典型案例（也是经常被问到的问题）包括：
如果一定要收敛一下以上的问题，那就是经常会被大家问到的一句话：
问：“DDD到底在什么情况下适用什么情况下适用？”
答：“业务逻辑复杂的系统。”
DDD的这个回答就很诡异了——到底什么是业务逻辑？到底什么是复杂？这回答面对上述4个问题基本就等于什么都没讲。
虽然我在之前的实践中，尝试过进行更加明确的说明，但是在业务和复杂性的关键定义上，基本上没有质的变化。我的相关解释请参看：《领域驱动实战思考（二）：用分段思想改进那些混乱的战略设计和战术设计》
换句话说，我认为DDD并没有真正的清晰定义和解答什么是“软件核心复杂性”，而是绕过了这个关键点，认为“问题都需要澄清和定义”，然后在所谓“战略设计”和“战术设计”的包装下，打着“澄清问题”的旗号，直接切进了“统一语言”和“协作设计”，以及系统架构和实现细节——有一种“别问，问就是需要澄清”的甩锅嫌疑。
而遗憾的是，在持续多年的修修补补之下，DDD的这个核心问题却丝毫未被解决。
那么，到底有没有什么方法能对于以上问题（业务、领域、复杂性）做出相对更加清晰的澄清和解答呢？
幸运的是，在和ThoughtWorks中国区CTO徐昊一起推动本公司工程效能变革的过程中，我了解并学习到了一套基于徐昊对于软件工程和架构设计多年的实践和思考，由他总结沉淀的，从“四色建模”所发展出来的，被称之为“8x Flow”的业务建模方法，有效的解答了我的困惑。
在此，我将利用一系列文章，将相关的思想、方法和配套的工程效能实践分享给大家，希望能够对大家有所帮助，同时也希望得到更多的碰撞和反馈。
在上一篇文章（沟通篇）中，我们讲了有关软件研发组织“在家办公”受到的沟通方面的挑战。
可能是在一家敏捷的公司待得久了，所以我很长一段时间认为“敏捷”在中国已经是家喻户晓不需要再去谈的东西。可是直到我后来做了技术顾问，开始为客户提供架构和工程能力的咨询服务时才发现，绝大多数技术架构和持续交付实践难以落地的问题，最后都会遇到团队不够敏捷这个关键障碍，而真正敏捷的团队，在整个中国的IT行业中，则是极少的。
因为不够敏捷，所以能够用于改进的带宽就不足，因为改进的带宽不足，所以就难以应用更好的技术实践，如此反复就变成了死循环……
而在众多导致不敏捷的原因中，首当其冲的，就和软件研发组织的项目管理方法和项目管理人员的能力有直接的关系。
而本次新型冠状病毒（2019-nCoV）疫情导致的“在家办公”的要求，则瞬间放大了相关影响——尤其是那些依赖于传统项目管理方法的软件研发组织。
那么，在这一篇中，我们就聚焦“传统的项目管理方法”和“敏捷的项目管理方法”的区别，来谈谈对于在家办公的影响：
最近“新型冠状病毒（2019-nCoV）”汹汹来袭，一时间“在家办公（Working From Home，简称WFH）”成了一个非常现实和火热的话题。我心想着：“这时候理应有篇写在家办公的文章”，但是又一想：“想必一定有很多人写”，所以一直没动笔。
结果呢，各种渠道和平台的在家办公类文章铺天盖地，无奈的是，里面大量的都是在卖自家产品，没几个在认真说在家办公的挑战和问题的。似乎买了某家的在线协作平台产品，就能真正实现在家办公了一样——如果真的靠买产品就能实现在家办公，那岂不是绝大多数的软件研发团队平时都应该在家办公吗？为啥还要天天车马劳顿的赶去公司上班？
这次突如其来的疫情所带来的在家办公一事，更像是一次针对软件研发组织敏捷程度的“国考”。在家穿着睡衣披头散发的办公，还都只是大家呵呵一笑找点乐子，但是如果长时间下去，还有多少软件研发组织能够笑到最后呢？
在IT行业，在家办公一直是一个非常火热的话题。我在加入ThoughtWorks之前，有过半年时间的在家办公尝试。在加入ThoughtWorks之后，在做培训、做开发、做咨询的过程中，阴差阳错的竟然实现了相当时间比例的在家办公。在我看来：
以绝大多数软件研发组织的敏捷实践水平之低，还谈不上如何在家办公。
从这篇文章开始，我将围绕制约在家办公的一些关键挑战，以多篇文章（每篇关注一个维度的方式）来谈一谈为什么在家办公是软件研发组织的“敏捷试金石”。
本篇，我们优先说一说：沟通成本。
我在2014年入职ThoughtWorks后，做了近4年的人才培养。在2018年底，我开始从事对外咨询和培训工作，然后又带着一群新技术顾问去对顾问要求比较“严苛”的客户那里做咨询。在这个过程中，一个让我割舍不掉，并且在潜意识中也无法停止思考的问题就是：怎么培养人？
尤其是与教毕业生和Junior的员工如何写代码和做项目相比，带Senior的人做咨询工作是有非常大的不同的。
这篇文章，就围绕我所精挑细选的“新技术顾问必读的十本书”出发，来给大家分享我在培养“通用型软件技术顾问”的过程中的一些思考。
也希望能够以这篇文章开始，将“如何培养软件技术顾问”这个问题进行不断的探索和总结，来补全我们过去一直以来所进行的“软件人才培养”的研究。以期日积月累，最后成书。
你是不是和我一样，是一个会使用一大堆编程语言的软件开发工程师？例如：
Java、C#、JavaScript、Ruby、Python、Go……
你是不是和我一样，会在电脑上装一大堆以上各种语言的“版本管理器（Version Mananger）”，为了管理和切换不同项目的运行时（Runtime）版本？例如：
sdkman、nvm、rvm、pyenv、gvm……
你是不是和我一样，是一个浪费了大量时间在选择某种语言的版本管理器上的“强迫症患者”？例如：
到底应该用sdkman呢还是jabbar呢？
到底应该用nvm呢还是n呢？
到底应该用rvm呢还是rbenv呢？
……
你是不是和我一样，被各种语言的版本管理器污染了硬盘还整的精神分裂呢？
你是不是和我一样，期待能够有种能够管理所有语言的版本管理器，从而“一统江湖”呢？
你是不是和我一样，平时使用macOS或者Linux操作系统呢？
如果以上答案都和我一样，那这篇神器推荐就是写给你的，让我们隆重介绍这款“一统江湖的语言版本管理器”：asdf-vm！
（对不起，我也用Windows，只是神器不支持……囧）
在我的上一篇文章中，给大家介绍了我在实践中对于DDD设计过程进行梳理的思考。本篇则是向大家整体介绍一下我的“DDD分段式协作设计”的步骤和内容。
同时，该方法的基准化操作手册，也在曾经的一篇文章中公开提供了下载，可以作为更细化的内容进行参考和使用。
由于DDD的相关概念和设计方法极多，相比其他市场上所能见到的操作手法，我在这里向大家所介绍的方法，更加聚焦如何能够确保达到“绝大多数人的60分”， 而非“极少数人的100分”，也就是说，我更加注重的是：
为此，我尽可能的通过实战检验，在一些需要凭借经验进行综合判断的场景，尽可能的提供虽然不完美但是可以降低选择成本的唯一选项或解释，从而争取让一线实施人员避免“二选一”或“看具体情况再说”这样莫能两可的纠结。
需要说明的是，不同的咨询师在实施DDD的设计过程中手法都不一样，我仅是从我所实施过的咨询项目出发，提供了一种经反复验证可工作的方式，并不代表本方法是唯一正确的。
在这里仅供参考，也欢迎大家进行交流。
2019年，在我对DDD进行基准化的过程中，遇到过非常多的挑战，其中一个便是：
DDD的设计过程，到底应该分为多少个阶段？每个阶段做什么事情？
这个困惑来自于书本上，以及其他咨询师在咨询过程中对于DDD设计和操作的差异：
对于实际的学习者和使用者来说，这种混乱的操作手法所形成的不一致和不流畅体验，对于坚持进行DDD设计和减少吵架来说，简直是一种毁灭性的影响。
在这个过程中，最让我感触深刻的，是在于大家在落地DDD的时候，使用了大量具有“二义性”的词汇，讽刺的是，这与DDD所强调的统一语言是背道而驰的。
其中对于上述混乱影响最大的因素之一，就是大家对于DDD的“战略设计”和“战术设计”认知不一致（甚至说是混沌）的问题。
所以，这篇文章，就是围绕这两个概念，来说一说我是如何在基准化的过程中解决这个问题，统一并形成较为流畅的分段式的设计过程的。
在这一年聚焦DDD设计，尤其是DDD的协作设计工作坊的咨询工作中，我发现客户同很多咨询顾问之间总是存在以下冲突：
结合我曾经在ThoughtWorks近4年的人员培养和教学经验，和这几年来的咨询经验，我能够理解客户这样要求，是因为希望能够实现方法论的规模化落地。而在方法论规模化落地的过程中，一个很重要的问题，就是绝大多数能力一般的人，都更习惯于依据“明确的指令”进行工作，而不是依赖自己“有限的经验”和“莫能两可的方法论”。
这篇文章就是记录我是如何来解决这个问题的。
一段时间以来研究和实践契约测试，发现如过去大家对于单元测试、集成测试、端到端测试等等测试理解不一致一样，绝大多数情况下都把契约测试理解或应用错了。
为了统一认知，写了个简介，以求被拍砖和拍人。