一文带你理解DDD邻域驱动设计

DDD领域驱动设计

是什么

DDD领域驱动设计是一种软件开发方法论和设计思想。通过定义领域模型，从而确定业务和应用的边界，保证业务模型和代码模型的一致

因为 DDD 主要应用在微服务架构场景，所以想要更好的理解 DDD 的概念，需要结合微服务架构来看:

微服务的拆分一直是业界的一个难题: 微服务拆分的粒度应该多大? 服务到底应该如何拆分? 服务之间的边界如何定义?

实际上微服务的拆分是门“艺术”

• 服务拆分的太细，项目复杂度会过高，接口的调用成本、服务运维成本大幅上升。

• 服务拆分的太粗，业务边界变得模糊，服务的合度还是过高，失去了微服务的优势

而 DDD 就是一个方法论，指导各个服务之间的工作更加清晰，从而划分出应用的边界，最终落实成服务的边界，代码的边界。

总结一下，就是让系统更贴合业务，让大型系统更利于独立建设和维护。

适用场景

1. 业务复杂的系统: 如金融系统、电商平台等，涉及的业务逻辑复杂且频繁变化。

2. 需要与多个部门或团队合作的大型项目

3. 长周期、长期维护的项目: DDD 强调可维护性与演化，适合需要长期维护和扩展的系统。

总结一下，大型的、跨部门协作的、长期维护的复杂项目

DDD和MVC

MVC架构其实很精粹，清晰，Controller负责业务逻辑的处理，Model代表和持久层交互的数据模型，View层负责视图展示。对于业务逻辑并不复杂，单一化的场景其实效率是很高的。但是随着业务的多变性和不断复杂化，MVC架构就会暴露以下问题：

• MVC架构没有边界划分的概念和规范，在复杂的业务场景下会造成盘根交错的逻辑依赖

• MVC仅反映软件架构的分层，不定义业务语义的抽象和表达

• MVC分割了数据和行为的表达，Model层（pojo）定义数据，Service层表述行为，会造成业务逻辑的首尾分离。

DDD价值

1. 统一语言

同一团队( 包含业务、运营、产品、质量等 )，所有角色的认知语言统一化，不论是在设计、文档编写、编码等任何环节，都使用同一种语言

1. 清晰的边界定义

划分领域和子域的边界，通过边界和核心实体的聚合与建立，定义出清晰的业务范围，避免边界纷争

1. 领域能力沉淀和复用

通过领域能力的沉淀和打磨，使业务和模型统一，也使领域能力得以传承。

1. 面向业务建模

基于现实业务做业务领域的抽象，切分数据和领域（业务）模型，从而降低整个软件复杂度。

开发人员应始终聚焦于领域模型，而不是传统理念中关注数据层和接口层的设计。

1. 设计和代码的等价

设计即代码，代码直观表现设计。好的DDD设计，在方案上一句代码都没有，但是却已经清晰的表明了所有的代码实现（尤其在代码结构、层次、定义上会感受得更清楚）。

1. 构建体系化思维

DDD的几个核心概念，要求负责人不能只从单点去看问题，需要从线和面上去深入理解，这点能很好的帮助个人去构建体系化思维的能力。

缺点

逻辑相对简单的业务和产品（比如一些小型公司的内部OA系统），用传统的MVC架构会更适合，构建也更快速

非业务形态产品和应用并不适合，比如bigdata。这类应用和业务专注于数据层的交互和适配，并无强业务语义类诉求，而DDD最关键的一部分就是业务领域的抽象和包装，切记，它解决的是负责业务问题。

DDD 的建设

首先 建立领域模型，根据业务划分领域边界，进而确定微服务的边界，然后再根据领域分块编码实现。

主要包括战略设计和战术设计两部分。

1. 首先第一步，根据业务诉求，提炼出整体的业务流程，同时拆解出里面的关键事件，角色，参与者等核心实例。整个拆解和梳理的方法论，目前业界有一些比较成熟的，比如事件风暴，四色建模法等，

事件风暴，就是邀请领域专家、架构师、开发人员、测试人员、产品经理、项目经理等团队人员一起参加讨论。描述个场景，大家在会议室里，搞一个大白板，参与者们将自己的想法和意见写在贴纸里并罗列到白板上，大家先发散思维进行讨论、记录。

战略设计

1. 这个阶段主要是从全局和顶层的视角，把整个业务语义转换为结构化分层。通过领域和子域的划分，同时结合通用域、支撑域、限界上下文等设计，分解问题复杂度，其实就是前面说到的“分而治之”的思想。

战术设计

1. 通过前面的战略设计阶段，已经把整个领域、边界、上下文等关键模块都梳理完成，现在就是从各个域中再