三年磨一剑，领域驱动设计布道师出版了《解构领域驱动设计》

Posted 2021-10-02 人邮异步社区

解构领域驱动设计

作者：张逸

本书全面阐释了领域驱动设计（domain-driven design，DDD）的知识体系，内容覆盖领域驱动设计的主要模式与主流方法，并在此基础上提出“领域驱动设计统一过程”（domain-driven design unified process，DDDUP），将整个软件构建过程划分为全局分析、架构映射和领域建模3个阶段。除给出诸多案例来阐释领域驱动设计统一过程中的方法与模式之外，本书还通过一个真实而完整的案例全面展现了如何进行领域驱动设计统一过程的实施和落地。为了更好地运用领域驱动设计统一过程，本书还开创性地引入了业务服务、菱形对称架构、领域驱动架构、服务驱动设计等方法与模式，总结了领域驱动设计能力评估模型与参考过程模型。本书提出的一整套方法体系已在多个项目中推广和落地。

本书适合希望领会软件架构本质、提高软件架构能力的软件架构师，希望提高领域建模能力、打磨软件设计能力的开发人员，希望掌握业务分析与建模方法的业务分析人员，希望学习领域驱动设计并将其运用到项目中的软件行业从业人员阅读参考。

成书历程

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

课程写作结束了。战略篇一共34章，约15.5万字；战术篇一共71章，约35.1万字。合计105章，50.6余万字，加上2篇访谈录、2篇开篇词与这篇可以称为“写后感”的后记，共110章。如此成果也足可慰藉我为之付出的两年多的艰辛时光！

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

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

• 解析，就是要做到知其然更知其所以然；
• 重构，则要做到青出于蓝而胜于蓝

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

如何阅读这样一本厚书

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

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

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

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

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

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

专业书评

本书的读者是幸运的！我运用领域驱动设计磕磕绊绊十余年，阅读本书，深感它是一本可与《领域驱动设计》和《实现领域驱动设计》互补的书。阅读本书，相当于吸收了很多本书的精华。本书对相关概念进行深刻阐述，并大胆突破、创新架构，在领域驱动设计落地方面非常出色。
——周吉鑫 京东资深业务架构师
在拿到本书时，读者就几乎综览了过去20多年的软件开发历程所提到的诸多重要元素。本书结合大量实务案例来探讨为何需要战略指导、为何需要以固有的战术设计范式指导实践，并辅以领域驱动设计统一过程的指导原则，指引读者逐步落地。本书不单纯以领域驱动设计来讲老生常谈的方法，而更像一位坐在你身边的资深架构师，与你结对进行系统架构设计，一起探索软件架构设计的奥秘。
——高翊凯 Amazon Web Services资深解决方案架构师
我熟读了几乎所有的领域驱动设计经典著作，但仍旧从张逸先生的书中获益良多。我认为本书的广度、深度与创新性已经可以与该领域的国际经典著作看齐。本书的出版是领域驱动设计理论界的一个重要事件，是对软件行业在领域驱动设计方面的巨大贡献，必将降低整个行业掌握领域驱动设计的门槛，加速领域驱动设计的普及。同为领域驱动设计布道者，我将向我的同行强烈推荐本书。本书也是我本人将来开展工作的重要理论指导。
——王立 微信支付12级专家工程师、技术领导者
近年来，随着微服务的流行，国内对领域驱动设计的研究和实践愈发多了起来。我对领域驱动设计的态度是：相对于战术设计，应该更看重战略设计。本书创造性地提出领域驱动设计统一过程，可以说是推陈出新、自成一家。本书内容丰满、探讨深刻，精彩之处甚多，留待读者去发现。
——于君泽（右军）技术专家

详细目录

领域驱动设计（domain-driven design ，DDD）需要应对软件复杂度的挑战！那么，软件复杂度 的成因究竟是什么，又该如何应对？概括而言，即：

• 规模——通过分而治之控制规模；
• 结构——通过边界保证清晰有序；
• 变化——顺应变化方向。

领域驱动设计对软件复杂度的应对之道可进一步阐述为：

• 规模——以子领域、限界上下文对问题空间与解空间分而治之；
• 结构——以分层架构隔离业务复杂度与技术复杂度，形成清晰的架构；
• 变化——通过领域建模抽象为以聚合为核心的领域模型，响应需求之变化。

子领域、限界上下文、分层架构和聚合皆为领域驱动设计的核心元模型， 分属战略设计和战 术设计，贯穿了从问题空间到解空间的全过程。

领域驱动设计的开放性是其生命长青的基石， 但它过于灵活的特点也让运用它的开发团队举 步维艰。我之所以提出领域驱动设计统一过程，正是要在开放的方法体系指导之下，摸索出一条行 之有效的软件构建之路，既不悖于领域驱动设计之精神，又不吝于运用设计元模型，通过提供简单 有效的实践方法，建立具有目的性和可操作性的构建过程。

领域驱动设计统一过程分为3个阶段：

• 全局分析阶段；
• 架构映射阶段；
• 领域建模阶段。

每个阶段的过程工作流既融合了领域驱动设计既有的设计元模型，又提出了新的模式、方法 和实践，丰富了领域驱动设计的外延。领域驱动设计统一过程对项目管理、需求管理和团队管理也 提出了明确的要求，因为它们虽然不属于领域驱动设计关注的范畴，却是保证领域驱动设计实践与 成功落地的重要因素。

领域驱动设计统一过程是对领域驱动设计进行解构的核心内容！