解构领域驱动设计：我对于领域驱动的认知

Posted 2021-05-01 技术琐话

写下本书内容第一个字的具体时间已不可考，从文档创建的时间看，本书的写作至少可以追溯到2017年11月，屈指算来，距今已是三载光阴流逝而过，为了本书，我已算得上呕心沥血。回想这悠悠三年，无论在万米高空的飞行途中，还是在蔚蓝海边的栖息之旅，抑或工作之余正襟危坐书桌之前，我的心弦一刻不敢放松，沉思于体系的构建，纠结于案例的选择，锱铢必较于每个文字的运用，我力求输出最好的文本，希望打造领域驱动设计技术书籍的经典！

我在ThoughtWorks的前同事滕云开我的玩笑，说：“老人家，你写完这本书，也就功德圆满了！”老人家是我在ThoughtWorks的诨名，虽然我对此称呼一直敬谢不敏，不过写作此书至今，我已心力交瘁，老人家的称谓也算名实相副了，至于是否“功德圆满”，就要交给读者诸君来品评了。

本书内容主要来自我在GitChat发布的课程《领域驱动设计实践》。该课程历经两年，完成于2020年1月21日。当时的我，颇有感慨地写下如此后记：

课程写作结束了。战略篇一共 34 章，15 万 5 千字；战术篇一共 71 章，35 万 1 千字；合计 105 章， 共 50 万 6 千余字，加上两篇开篇词与这篇可以称为写后感的后记，共108 章，算是凑齐了一百单八将。如此成果也足可慰藉我为之付出的两年多艰辛时光！

我对《领域驱动设计实践》课程的内容还算满意，然而，随着我对领域驱动设计理解的蜕变与升华，我的“野心”也在不断膨胀，不仅希望讲清楚该如何实践领域驱动设计，还企图对这套方法体系进行深层次的解构。这也是本书书名《解构领域驱动设计》得名的由来。

所谓“解构”，就是解析与重构：

• 解析，就是要做到知其然更知其所以然

• 重构，则要做到青出于蓝而胜于蓝

我钦佩并且尊敬Eric Evans对领域驱动设计革命性的创造，他对设计的洞见至今让我赞赏不已，尤其在我彻底吃透限界上下文的本质之后，结合微服务之大行其道，更让我彻底佩服他的远见卓识；然而，尊敬不是膜拜，佩服并非盲从，在实践领域驱动设计过程中，我确实发现了这套方法体系天生存在的不足，于是，我在本书提出了GitChat课程不曾涵盖的领域驱动设计统一过程（Domain-Driven Design Unified Process），相当于站在Eric Evans的巨人肩膀上，我构建了自己的一套领域驱动设计知识体系。

领域驱动设计统一过程的提出，从根基上改变了本书的结构，我调整和梳理了写作的脉络，呈现出与《领域驱动设计实践》课程迥然有别的全新面貌，整本书不再满足于粗略地将内容划分为战略篇和战术篇，而是在领域驱动设计统一过程的指导下，将该过程的全部三个阶段作为本书的三个核心篇章：全局分析、架构映射与领域建模，再辅以开篇和融合，共分为五篇二十五章，全面而完整地表达了我对领域驱动设计的全部认知与最佳实践。在对内容做进一步精简后，本书仍然达到了43万余字，算得上是软件技术类别的大部头著作了。

该如何阅读这样一本厚书？

若你时间足够充裕，又渴望彻底探索领域驱动设计的全貌，建议还是按部就班、循序渐进地开始你的阅读之旅。或许在阅读开篇的三个章节时，你会因为太多信息量的一次性涌入，产生迷惑、困扰和不解，那只是因为我期望率先为读者呈现领域驱动设计的整体面貌，在获得整体印象之后，哪怕只是在脑海中存留了如雾一般朦胧的轮廓，也足以指导你开启对设计细节的理解和认识。

若你追求高效阅读，又渴望寻求困惑于领域驱动设计问题的答案，当然可以根据目录按图索骥，精准定位你最为关心的技术讲解。或许你会失望，甚至产生质疑，从目录中你获得了太多全新的概念，而这些概念从未见诸于任何一本领域驱动设计的书籍，那只是因为这些概念都是我针对领域驱动设计提出的改进与补充，它们是我解构全新领域驱动设计知识体系的得意之笔。——要不然，一本技术书籍怎么会写三年之久呢？

我自鸣得意的开创性概念一一罗列于此：

• 业务活动：它是全局分析的基本业务单元，在统一语言的指导下完成对业务需求的抽象，既可帮助我们识别限界上下文，对它的细节分析还可以帮助开发团队开展领域分析建模、领域设计建模和领域实现建模；业务活动的粒度也是服务契约的粒度，由此拉近了需求分析与软件设计的距离，甚至可以说打通了需求分析与软件设计的鸿沟。

• 菱形对称架构：虽然该模式脱胎于整洁架构与六边形架构，但它更为简洁，与限界上下文的搭配可谓珠联璧合，既保证了限界上下文作为基本架构单元的自治性，又融入了上下文映射的通信模式，极大了丰富了设计元素的角色构造型。

• 场景驱动设计：采用过程式的设计思维，却又遵循面向对象的职责分配，从而在提高设计质量的同时降低了开发团队的设计门槛，完成了从领域分析模型到领域实现模型的无缝转换，并可作为测试驱动开发的前奏，让领域逻辑的实现变得更加稳健而高效。

以上概念皆为领域驱动设计统一过程的设计元素，同时又能与领域驱动设计的固有模式有机融合。至于我对软件复杂度成因的剖析，对价值需求和业务需求的划分，在领域驱动设计统一过程基础上建立的领域驱动设计魔方、参考过程模型与能力评估模型，诸多新概念、新方法、新模式、新体系虽说都出自我的一孔之见，但自觉可圈可点，确乎来自于我的一线实践和总结。至于内容的优劣，还是交给读者诸君来品判吧。

附：张逸老师的分享如下：

2月前某夜，组织了张逸兄的一个小场分享。张逸兄私下坦言，3年前我写了2个专栏，自以为对于限界上下文的认识已经足够深刻。3年来，与同行分享交流、持续实践和不断思考，始觉今日才有“登堂入室”之感。于是我在写书的过程中，完全重构了思考逻辑。这个ppt亦是最新思考逻辑的一次交流。

数据驱动设计，是一种常见的方式。Shipment 这张表就冗杂了诸多字段信息。

经典的几种架构定义的描述：

总结：

软件的架构包含了如下要素：

功能分解的软件元素

软件元素的关系

软件元素和环境的关系

指导设计与演化的架构原则

限界上下文：

看这个例子，bounded，边界，保护！作为乘客这个role，我参与的活动行为和作为咨询师是不一样的。

确定了领域后，就要保护领域不能随意被“侵犯”，而保护的依据，就是“限界上下文”。Eric Evans 用细胞来形容限界上下文，因为“细胞之所以能够存在，是因为细胞膜限定了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。”这里，细胞代表上下文，而细胞膜代表了包裹上下文的边界。

如图，一个运输业务设计到运费，运输计划毋庸置疑属于“运输上下文”，运费结算肯定属于“财务上下文”。运费的规则制定其实也属于“财务上下文”，这个案例没有对这部分展开讨论。

传统的三层架构，或者模块划分，是按照技术分层的，比如MVC模式。而限界上下文涵盖的是领域纬度。

限界上下文的四个特性：

最小完备、稳定空间、自我履行、独立进化

从问题域（空间）到解决方案域（空间）

 往期推荐：

• 
  

• 
  

• 
  

• 
  

• 
  

•    ……

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。