前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、领域驱动设计的精髓

1、边界是核心

1）分析边界

a、第一重边界（目标系统范围）

从全局分析开始，我们就需要确定目标系统的利益相关者与愿景以确定目标系统的范围。它的边界是领域驱动设计问题空间的第一重边界，可以用于界定问题空间；帮助团队明确了哪些功能属于目标系统的范围。系统范围边界的大小等于问题空间的大小，也就决定了目标系统的规模。确定系统范围是探索问题空间的主要目的，同时，也是求解问题空间的重要参考

b、第二重边界（子领域）

问题空间通过核心子领域、通用子领域和支撑子领域进行分解，以更加清晰地呈现问题空间，同时降低问题空间的复杂度。子领域确定的边界是领域驱动设计问题空间的第二重边界

2）设计边界

a、第一重边界（系统上下文）

到了架构映射阶段，利用组织级映射获得的系统上下文成了领域驱动设计解空间的第一重边界。通过系统上下文明确哪些属于目标系统，哪些属于伴生系统，即可清晰地表达当前系统与外部环境之间的关系、确定解空间的规模大小。

b、第二重边界：（限界上下文）

通过业务级映射获得的限界上下文是领域驱动设计解空间的第二重边界，可以有效地降低系统规模。

无论是在业务领域，还是架构设计，或者团队协作方面，限界上下文边界都成了重要的约束力。外部世界的规则是契约、通信以及系统级别的架构风格与模式，内部世界的规则是分层、协作以及类级别的设计风格与模式。”

c、第三重边界：（网关层）

在限界上下文内部，网关层与领域层的隔离成了领域驱动设计解空间的第三重边界。菱形对称架构形成了清晰的内外边界，有效地隔离了业务复杂度与技术复杂度。将领域层作为整个系统稳定而内聚的核心，是领域驱动设计的关键特征

d、第四重边界：（领域层）

若要维持领域内核的稳定性，高内聚与松耦合是根本要则。为此，领域模型引入了聚合这一最小的设计单元。它从完整性与一致性对领域模型进行了有效的隔离，

2、纪律是关键

不管一套方法体系多么完美，如果团队不能严格地执行方法体系规定的纪律，一切就都是空谈。领域驱动设计本身没有多难，但是持续地保持这个领域模型的更新和有效，并且坚持在工作中用统一语言来讨论问题是很难的。纪律才是关键。

领域驱动设计强调对边界的划分与控制。如果团队在实施领域驱动设计时没有理解边界控制的意义，也不遵守边界的约束纪律，边界的控制力就会被削弱甚至丢失。

1）三大纪律

1、领域专家与开发团队在一起工作；

2、领域模型必须遵循统一语言；

3、时刻坚守两重分析边界与四重设计边界。”

2）八项注意

1、问题空间与解空间不要混为一谈；

2、一个限界上下文不能由多个特性团队开发；

3、跨进程协作通过远程服务，进程内协作通过应用服务；

4、保证领域分析模型、领域设计模型与领域实现模型的一致；

5、不要将领域模型暴露在网关层之外，共享内核除外；

6、先有领域模型，后有数据模型，保证二者的一致；

7、聚合的关联关系只能通过聚合根ID引用；

8、聚合不能依赖访问外部资源的南向网关。”

二、领域驱动设计能力评估模型

领域驱动设计能力评估模型(domain-driven design capability assessment model，DCAM)，要实施领域驱动设计，必须提高团队成员的整体能力

1、敏捷迭代能力

领域驱动设计之所以在近十余年未能取得举足轻重的成功，其中一个原因就是它没有与敏捷软件开发过程结合起来。敏捷开发的诸多实践，包括特性团队、持续集成、迭代管理等都可以为领域驱动设计的实施保驾护航

等级	迭代计划	团队协作	需求管理	反馈机制
初始	无固定计划，任务随意安排，常临时增减任务	成员职责模糊，沟通混乱，信息传递不畅	需求模糊，无优先级划分，频繁变动	无反馈渠道，不总结问题
成长	有初步计划，含迭代周期和目标，但任务规划欠妥	有职责划分，定期沟通，协作配合度一般	能整理需求，有简单优先级排序，变更管理不完善	建立基本反馈渠道，有改进意识但执行不足
成熟	计划详细，考虑任务时间、资源及依赖关系，能灵活调整	成员职责清晰，沟通高效，协作默契	需求文档规范，有严格变更管理流程，按优先级开发	反馈渠道畅通，深入分析反馈，持续改进

2、需求分析能力

领域主要来自问题空间的业务需求。要从复杂多变的真实世界中提炼出满足建模需求的领域知识和领域概念，就要求团队具备成熟的需求分析能力

等级	需求理解	分析方法	需求文档	与团队协作
初始	仅能理解表面需求，易忽略关键信息	依赖经验判断，无系统分析方法	文档简单，内容缺漏多，格式不规范	很少与团队沟通，信息共享不足
成长	能把握大部分需求，偶尔遗漏细节	开始运用基础分析工具和方法，如头脑风暴、流程图等	文档较完整，格式初步规范，有一定可读性	能与团队沟通交流，获取部分反馈
成熟	精准把握需求，挖掘潜在需求和业务价值	熟练运用多种分析方法，如用例分析、数据分析等，综合评估	文档全面、详细、规范，逻辑清晰，可指导开发	深度参与团队协作，与各方密切沟通，及时调整需求

3、领域建模能力

团队成员的领域建模能力是推行领域驱动设计的基础，也是领域驱动设计有别于其他软件开发方法的根

等级	分析模型	设计模型	实现模型
初始	对领域模型概念模糊，仅能理解简单示例	只能构建简单、孤立的模型，缺乏系统性，模型结构混乱，难以反映业务核心	模型应用局限，无法有效解决实际业务问题，与业务流程脱节
成长	理解领域模型基本概念和作用，能识别常见模型元素	能构建较复杂模型，考虑业务关联和流程，但存在部分瑕疵，模型扩展性和复用性不足	能在部分业务场景应用模型，解决一般性问题，开始与业务流程结合
成熟	深刻理解领域模型本质和价值，熟悉多种模型架构和设计原则	构建的模型精准、全面、灵活，具备良好扩展性和复用性，准确反映业务全貌和核心	模型广泛应用于各类业务场景，有效驱动业务流程优化和创新，与业务深度融合

4、架构设计能力

如果说领域建模完成了对问题空间真实世界的抽象与提炼，架构设计就是在解空间中进一步对领域模型进行规范，建立边界清晰、风格一致的演进式架构

等级	架构认知	设计能力	方案落地
初始	对架构概念一知半解，仅了解基础架构类型	只能设计简单、单一功能架构，缺乏整体规划，组件间耦合度高	架构方案难以落地，在技术选型、资源协调上困难重重，无法满足业务需求
成长	掌握架构基本概念与常用架构模式，明白架构对系统的关键作用	能设计复杂系统架构，考虑性能、可维护性等因素，但存在部分缺陷，如扩展性不足	架构方案基本可落地，能解决常见技术问题，推动业务正常运转
成熟	对架构有深刻见解，熟悉前沿架构理念与技术，能根据业务特点选择合适架构	设计的架构全面且高效，具备高可用、高性能、高扩展等特性，充分契合业务发展	架构方案顺利落地，有效协调各方资源，助力业务快速迭代，推动技术创新

三、领域驱动设计参考过程模型

1、从需求调研开始，参考过程模型建议使用商业模式画布对问题空间进行探索，获得利益相关者、系统愿景和系统范围，它们共同构成了目标系统的价值需求。

2、根据价值需求的利益相关者，运用服务蓝图与业务流程图对业务需求进行梳理，获得业务流程。对业务流程按照业务目标进行时间上的阶段划分，就可以获得业务场景。

3、对业务场景进一步分析，可以获得代表服务价值的业务服务。业务流程、业务场景和业务服务共同构成了目标系统的业务需求。

4、在系统愿景与系统范围的指导下，利用功能分类策略对问题空间进行分解，获得由核心子领域、通用子领域和支撑子领域组成的子领域。

5、参考全局分析阶段确定的价值需求，绘制业务序列图，**通过 C4 模型的系统上下文图 **最终确定系统上下文。它确定了整个解空间的边界，明确了目标系统的解决方案范围，有助于我们确定哪些系统是目标系统、哪些系统是伴生系统，也确定了利益相关者、目标系统、伴生系统之间的关系。

6、在系统上下文边界的约束下，以 V 型映射过程对业务服务表达的领域知识进行归类和归纳，获得体现业务能力的限界上下文，并运用菱形对称架构体现限界上下文的内部架构。

7、需求分析人员在编写了业务服务规约之后，针对 业务服务绘制服务序列图，结合业已识别出来的限界上下文，确定上下文映射模式，并为目标系统定义服务契约。最后在系统上下文边界的约束下，根据子领域和限界上下文之间的关系，确定系统分层架构