DDD 概述

前言

为什么需要DDD

微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。

如何确定，是否有相关理论或知识体系支持呢？

2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

image.png

image.png

一、DDD基础：

1.DDD 的核心知识体系：

image.png

2.DDD的设计思路：

1.战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

2.战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现

3. 战略和战术设计常用方法

• 四色建模法

image.png

image.png

• 用例分析法

image.png

• 事件风暴法

image.png

• 限界笔纸法

image.png

image.png

4.用三步来划定领域模型和微服务的边界：

一步： 在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步： 务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。

第三步： 根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图根据领域实体之间的业务关联性，将业里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离

3.DDD 与微服务的关系：

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署

4.核心域、支撑域和通用域

核心域: 决定产品和公司核心竞争力的子域是，它是业务成功的主要因素和公司的核心竞争力。

通用域: 没有太多个性化的诉求，同时被多个子域使用的通用功能子域是。

支撑域: 还有一种功能子域是必需的，但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域

5.限定上下文：

通用语言确定了项目团队内部交流的统一语言，而这个语言所在的语义环境则是由限界上下文来限定的，以确保语义的唯一性。

而领域专家、架构师和开发人员的主要工作就是 通过事件风暴来划分限界上下文。限界上下文确定了微服务的设计和拆分方向，是微服务设计和拆分的主要依据。如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务。

上下文映射图-Context Map-包含项目的限界上下文和他们之间的集成关系。

一份清晰的领域上下文映射关系图，能够帮助我们明确各个业务之间的关系，在进行业务分工的时候也能够有所依据。在ddd中各个上下文之间有多种关系，包括合作、防腐、遵奉等等，我们基于简单认知对客户领域的领域关系做了如下梳理（为了图例简单，这里并不包含所有的和外部领域的交互，只是列出几个作为代表）：

两种基本的集成关系：上游upstream和下游downstream。

组织模式和集成模式的定义：

• 合作关系（partnership）：两个限界上下文的团队要么一起成功，要么一起失败，这两个团队就是一种合作关系。
• 共享内核（shared kernel)：共享模型和代码。
• 客户方-供应方开发（customer-supplier development）：上下游关系。
• 遵奉者（conformist）：上下游关系，上游团队没有动力提供下游团队所需要的东西。
• 防腐层（anticorrupttion Layer）（ACL）：某些关系无法顺利实施，该层作为上游系统的代理向你的系统提供服务。
• 开放主机服务（open host service）（OHS）：定义一种协议，让你的其他子系统通过该协议来访问你的服务。
• 发布语言（published language）（PL）：发布一种共享语言完成集成交流，通常和开放主机服务一起使用。
• 另谋他路（separate way）：声明两个上下文不存在任何关系。
• 大泥球（big ball of mud）：混杂在一起的模型。

实践：识别自己的限界上下文，识别出那些不该属于其中的概念，将这些概念放在另一个上下文中，再在图中标明两个限界上下文之间的关系。

image.png

左上角的五个领域都是归属于客户领域，互相之间都是共生共存的关系（PartnerShip，简称PS）。而右下角的几个上下文都是外部领域，需要通过防腐层（Anticorruption Layer，ACL）来转换交互，以隔离业务。箭头的方向标明了各个子域之间的上下游业务关系。

子域和限界上下文最好保持一对一的关系。

6.实体和值对象：

实体和值对象的目的都是抽象聚合若干属性以简化设计和沟通，有了这一层抽象，我们在使用人员实体时，不会产生歧义，在引用地址值对象时，不用列举其全部属性，在同一个限界上下文中，大幅降低误解、缩小偏差，两者的区别如下：

①两者都经过属性聚类形成， 实体有唯一性，值对象没有。在本文案例的限界上下文中，人员有唯一性，一旦某个人员被系统纳入管理，它就被赋予了在事件、流程和操作中被唯一识别的能力，而值对象没有也不必具备唯一性。

②实体着重唯一性和延续性，不在意属性的变化，属性全变了，它还是原来那个它；值对象着重描述性，对属性的变化很敏感，属性变了，它就不是那个它了。

③战略上的思考框架稳定不变，战术上的模型设计却灵活多变，实体和值对象也有可能随着系统业务关注点的不同而更换位置。比如，如果换一个特殊的限界上下文，这个上下文更关注地址，而不那么关注与这个地址产生联系的人员，那么就应该把地址设计成实体，而把人员设计成值对象。

有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析。如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象。如果这个对象是多条且需要基于它做查询统计，我建议将它设计为实体

image.png

7.如何设计一个聚合：

第 1 步：采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等等。

第 2 步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。判断一个实体是否是聚合根，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。图中的聚合根分别是投保单和客户实体。

第 3 步：根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。在图中我们构建了客户和投保这两个聚合。

第 4 步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。这里我需要说明一下：投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。从图中我们还可以看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。

第 5 步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。

这就是一个聚合诞生的完整过程了。

8.聚合的设计原则：

聚合内的实体对象数据一致性，边界之外的数据和聚合内的互不影响，也就是说一个聚合内的数据是一起的

设计小聚合，大聚合会导致实体太多，高频操作导致事务大，并发等问题

聚合之间的关联通过聚合根ID进行关联

通过应用层进行领域编排或者通过事件机制

9.领域事件：

为了多个聚合之间的交互方式：1.领域事件 2通过应用层编排

1.领域内的事件: 通过本地事件表存储，通过eventbus发布事件

2.领域外的事件: 1.通过消息队列 2.通过公共的事件库通信

二、DDD进阶：

1.DDD分层架构：

image.png

1.用户接口层

用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。

2.应用层

应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。这里我要提醒你一下：在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。另外，应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

3.领域层

领域层的作用是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。这里我要特别解释一下其中几个领域对象的关系，以便你在设计领域层的时候能更加清楚。首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。其次，你要知道，实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马，它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

4.基础层

基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库持久化。基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。比如说，在传统架构设计中，由于上层应用对数据库的强耦合，很多公司在架构演进中最担忧的可能就是换数据库了，因为一旦更换数据库，就可能需要重写大部分的代码，这对应用来说是致命的。那采用依赖倒置的设计以后，应用层就可以通过解耦来保持独立的核心业务逻辑。

2.整洁架构：

整洁架构整洁架构又名“洋葱架构”。

为什么叫它洋葱架构？

看看下面这张图你就明白了。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。

image.png

在洋葱架构中，各层的职能是这样划分的：

1. 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。

2. 领域服务实现涉及多个实体的复杂业务逻辑。应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。

3. 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。

4. 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。

5. 六边形架构

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。

六边形架构的核心理念是：应用是通过端口与外部进行交互的。

我想这也是微服务架构下 API 网关盛行的主要原因吧。也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。

image.png

六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：

1. 红圈内的六边形实现应用的核心业务逻辑；
2. 外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。

三种微服务架构模型的对比和分析

虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但你不要被它们的表象所迷惑，这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想。

image.png

我们看下上面这张图，结合图示对这三种架构模型做一个分析。

请你重点关注图中的红色线框，它们是非常重要的分界线，这三种架构里面都有，它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。

红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的，有的业务逻辑属于领域模型的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中划分了应用层和领域层，来承担不同的业务逻辑。

领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。

应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。

可以说，这三种架构都考虑了前端需求的变与领域模型的不变。需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变。但总体来说，不管前端如何变化，在企业没有大的变革的情况下，核心领域逻辑基本不会大变，所以领域模型相对稳定，而用例和流程则会随着外部应用需求而随时调整。把握好这个规律，我们就知道该如何设计应用层和领域层了。

架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小。面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。

融合 DDD、洋葱架构、整洁架构、CQRS的清晰架构

image.png

以下公司在使用DDD：

阿里巴巴

阿里巴巴-COLA框架

腾讯微信

去哪网

网易

京东科技

百度爱番番

美团

小米有品

VIVO

有赞

爱奇艺

......

学习资料

代码

https://github.com/alibaba/COLA

https://github.com/xtoon/xtoon-boot-ddd

https://github.com/ouchuangxin/leave-sample

https://github.com/Air433/dddbook

https://github.com/1991wangliang/springboot-ddd-demo