文章目录

一、领域驱动设计概念

1、基本概念

（1）通用语言

领域驱动设计，作为一个技术、产品、用户通用的语言进行沟通，极大地降低了沟通成本与沟通失真问题。

（2）领域设计4层模型

在这里插入图片描述

（3）DDD适合的场景

DDD既不是UI导向（SMART UI）、也不是数据导向（UML），而是以产品为导向，并不是用户所使用的产品，而是整个产品的业务逻辑。
适合中大型项目、API经济、中台化，可以借鉴DDD进行对微服务进行拆分。

2、领域、子域、界限上下文

领域（Domain）：具备一个完整的，在一个市场里面赚钱的能力。比如说二手车市场、电商领域、宠物托管平台。

领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
子域（SubDomain）：比如支付子域、商品子域、用户认证子域。

界限上下文（Context）：所谓上下文，就是为了解决子域的问题的。比如支付上下文，认证上下文。

子域提出问题空间，界限上下文提供解决空间。

3、核心子域、支撑子域、通用子域

在这里插入图片描述
核心域：核心域就是一个领域的核心。
比如说电商平台有哪些核心域：产品信息核心域、支付交易核心域、物流域，自然也就对应着产品信息上下文、支付上下文、物流上下文。

支撑子域：支撑核心域正常工作的子域。比如用户行为分析域、风控域，自然也有对应的界限上下文。

通用子域：一些业内通用的子域，比如用户认证系统，可以通过购买第三方的平台来实现。

4、界限上下文的关系

在这里插入图片描述
界限上下文的内容，就代表着对应的子域的功能。

界限上下文的上游（U-upstream）提供服务，下游（D-downstream）接收服务。

Conformist：跟随者关系。一定要跟某个上游系统绑定，但别人是主，本系统是从。

ACL（Anticorruption Layer）：Open Host Service（RPC、消息队列等）/Published Language（xml、json等） ，反腐层。集成遗留系统，又不能强制老系统更新，新系统要做个适配器层来转换模型。

partnership：更紧密的合作伙伴关系。

Shared Kernel：共享内核。两服务之间紧密合作，代码模型可以提取成通用组件共享。

Separate Ways：分离模式。两个微服务没有任何联系。

Customer Supplier Teams（客户供应者模式）：强依赖，上下游系统开发合作顺利，对模型逻辑修改反应迅速。常见于消息队列的两端。

Single Bounded Context（合并上下文模式）：单个界限上下文，两服务如一家人，紧密到无法分开。一切模式要素都是共享的。

5、领域模型的要素 - 实体、值对象、聚合

（1）实体

（比如说一个学生）
唯一标识（用户提供、应用生成UUID/GUID、持久化生成）。
数据可变。
生命周期管理。（订单状态管理）
实体的唯一标识是实体与实体，聚合与聚合之间的纽带。

（2）值对象（Value Object）

（比如说一个学生中的某个属性，居住地、性别、性格等等）
无标识。（不唯一）
数据不可变，可复制，可替代。
整体性。（比如：￥100 - 两个概念一个整体，山东省济南市 - 两个概念一个整体）
通常用来做实体的度量和描述。

（3）聚合（Aggregate）

（比如一个班级，有学生、书）
事务一致性边界。（各种动作的数据一致性、行为一致性，比如说所有学生一起上课、下课）
聚合之间通过聚合根（通常为聚合同名实体）进行沟通。
尽量缩小聚合（通常使用最终一致性和领域消息）。（缩小聚合事务复杂度就缩小了）
聚合是创建、发布领域事件和操作资源库的操作主体。

（4）案例分析

在这里插入图片描述

6、构建领域模型 - 工厂、库、领域服务

（1）工厂（Factory）

用于创建聚合和实体，可以用工厂类、工厂方法模式、创建者模式来实现。
实现了对象的解耦。
封装复杂操作过程。

（2）资源库（Repository）

实现对聚合的增删改查。
对接持久化机制（如Hibernate）。
和DAO、Mapper类似，但更侧重集合的处理。
封装复杂操作过程。

（3）领域服务（Domain Service）

无状态。
无法归为实体和值对象。
业务操作过程，对领域对象进行转换。
如：密码加密服务、文字转换服务、应收账款和应付账款对账。

7、反腐层

反腐层（Anti-corruption layer，简称 ACL）介于新应用和旧应用之间，用于确保新应用的设计不受老应用的限制。是一种在不同应用间转换的机制。

创建一个反腐层，以根据客户端自己的域模型为客户提供功能。该层通过其现有接口与另一个系统进行通信，几乎不需要对其进行任何修改。因此，反腐层隔离不仅是为了保护你的系统免受异常代码的侵害，还在于分离不同的域并确保它们在将来保持分离。

反腐层是将一个域映射到另一个域，这样使用第二个域的服务就不必被第一个域的概念“破坏”。

在这里插入图片描述

二、领域建模方法论

1、企业架构法

在这里插入图片描述

2、面向服务设计法（SOA）

在这里插入图片描述

3、用例分析法

在这里插入图片描述

4、四色建模法

红色：时标型（Moment-Interval）对象。
绿色：PPT（Party/Place/Thing）对象。
黄色：角色（Role）对象。
蓝色：描述（Description）对象。
在这里插入图片描述

5、初识Event Storming事件风暴

演进式架构和迭代式开发。
微服务拆分和向前兼容。
如何和产品业务人员沟通。
有没有一个可以在喝茶聊天中完成微服务拆分的方法？

在这里插入图片描述
在这里插入图片描述

6、领域模型的选择 - 贫血、充血模型

所谓的血，就是业务逻辑。

贫血：getter+setter方法，每个领域并没有太多业务逻辑，更多的业务逻辑在更上层。
充血：更符合领域驱动设计，应用逻辑为主、数据管理为辅。get、set方法是私有的，对外暴露的是更加丰富的有血有肉的方法动作。

贫血模型和充血模型各有优势：
贫血模型：上手快、发展受限，适合应用逻辑简单、信息记录类型的业务。
充血模型：上限高、适合三高项目，适合逻辑复杂、信息处理类型的业务。

7、洋葱圈模型

在这里插入图片描述

三、领域事件

1、初识领域事件Domain Event

异步通信，符合事件驱动风格。
通常用消息队列（MQ），可以实现削峰填谷。
但是要处理消息丢失、消息重复的问题。
在这里插入图片描述
在这里插入图片描述

2、领域事件，代码实例

（1）生产者发布事件

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

（2）消费者订阅事件

在这里插入图片描述

在这里插入图片描述

（3）EventStore做事件存储

在这里插入图片描述
在这里插入图片描述

（4）定时任务轮询投递事件

在这里插入图片描述
在这里插入图片描述

3、领域事件与CQRS

（1）什么是CQRS

CQRS：Command Query Responsibility Separation。（写和读的责任分离）
Command：执行动作，返回void。（行动可能会改变聚合、实体、值对象的内容）
Query：只查询，不修改对象状态。

适用CQRS的风格：事件驱动系统风格、管道过滤器风格。

（2）CQRS和ES事件溯源

普通CQRS：做数据的增删改查，对于数据无法溯源。
在这里插入图片描述

事件溯源：数据只做增和查，可以做到事件溯源。
在这里插入图片描述

四、案例：敏捷项目管理系统

1、功能分析

项目管理系统，涉及项目发布、代办、状态、任务等等。
在这里插入图片描述
在这里插入图片描述

2、子域划分

在这里插入图片描述

3、定义实体、值对象、聚合

（1）聚合根

领域驱动设计中，对外提供功能的只有聚合根的功能，聚合根里面的实体尽量只对聚合根提供服务。
聚合根的子对象，尽量都用实体对象封装。
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

（2）值对象

值对象不提供独有的ID，全部通过快速复制快速创建，永不修改来实现这些值对象的描述性的信息。
在这里插入图片描述

在这里插入图片描述

（3）实体

把子对象用实体的形式进行封装，成员变量private，set和get方法private，让它们更加生动的操作protected，让其他成员来访问。，聚合根里面的实体尽量只对聚合根提供服务。
在这里插入图片描述

（4）聚合

把聚合根、值对象、实体打包起来，就形成了聚合。
在这里插入图片描述

4、落地工厂、库、领域服务

（1）工厂

在这里插入图片描述
在这里插入图片描述

（2）资源库

在这里插入图片描述

（3）领域服务

在这里插入图片描述

5、落地反腐层

（1）完整图示

在这里插入图片描述

（2）领域服务

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

（3）适配器：进行适配+调用上有服务

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

6、应用服务

应用服务的方法与工厂、资源库之间的关联：
在这里插入图片描述

7、建模的核心要素 - 隐性的概念显性化

隐性的概念显性化：多种不同的逻辑封装到一起，按情况进行处理。

隐形的上下文显性化。

封装多对象行为。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

8、规则选择 - 策略模式

在这里插入图片描述

9、规则拼装 - 组合模式

在这里插入图片描述

10、事件风暴 - Event Storming

（1）事件Event

事件即事实，即在业务领域中那些已经发生的事件就是事实，并可能需要保存下来或者让“别人”响应。

事件是对系统产生了业务上的影响的动作，相对的，如果仅仅是数据查询操作，则只会对系统产生技术上的影响，如CPU上升或者内存上升等。

注意：一般查询操作都不会触发事件的产生，所以查询操作不是事件，如点击了查询按钮显示了数据列表，一般情况下不会有类似于：数据已查询或列表已查询，这样的事件。

事件使用正方形橘黄色的便利贴表示，并且是过去式，如：用户已注册（User Registered），激活邮件已发送（ActivationEmail Sended）等。

（2）痛点/问题/关键点（IDEAS, RISKS）

关键点用红颜色的贴纸表示。

表示不确定的点、有风险的点或者需要特别注意的点，一般贴在事件旁边，代表这件事情值得特别关注。

（3）命令Command

决策命令产生了事件，可理解为产生事件的动作，与事件一一对应。如用户已注册（User Registered）事件对应的决策命令就是注册用户（Register User）。

决策命令用正方形蓝色便利贴表示，在实践中只需要将事件“反过来”就行了。

（4）聚合Aggregate

某个Actor在某个聚合调用某种Command产生了某个Event。

比如前面的用户已注册（User Registered）事件，是由普通用户（Normal User）在注册薄（Register）上调用注册用户（Register User）这个命令而产生。

聚合使用紫色即时贴表示。

（5）外部系统External System

Event不一定由前面所说的某个Actor触发Command而产生，也可能是由外部系统或者某种规则自动触发Command而产生。

外部系统使用绿色即时贴表示。

（6）第一阶段成果

在这里插入图片描述

（7）构建微服务间关联关系

在这里插入图片描述

（8）形成类图

在这里插入图片描述

（9）事件风暴核心思想

由下而上，更快：平时我们拆分都是从上层架构师进行总的模块拆分，再分到每一个模块里面。事件风暴从一个个事件开始，从下往上的考虑，出手更快。

事件驱动，更新：事件风暴是由事件驱动的，非常容易更新，当整个架构定下来以后，一旦用户体验有所变化，只需要改变对应的聚合。

团队破冰，更嗨：面前贴一张白纸，通过这种沟通，团队之间心平气和的把服务拆分的非常完美。

10、DDD模型下的代码分层模型

在这里插入图片描述

DDD实践_如何使用DDD设计代码模型

五、案例：电商场景领域模型设计

1、子域

核心子域：买家、支付、履约、卖家、市场、用户、风控、客服、搜索、财务、产品、定价、认证、内部、推荐、社交、合作、库存。

通用和支撑子域：数据平台、数据科学、负载管理、内容管理、消息通告、安全加固、基础架构、应用平台、质量保证、集成发布、遥测监控、合规审计。

2、上下文

认证上下文：注册认证、用户登录、访客登录、内部登录、身份验证、令牌管理。

用户上下文：用户联系、用户服务、用户设备、用户喜好、用户背调、用户支付、用户行为、用户设置、用户订单、用户发布、用户折扣、会籍管理。

市场上下文：折扣策略、优惠券、促销管理、用户粘性、SEO、SEM。

搜索上下文：公共搜索、个人搜索、信息编目。

客服上下文：语音客服、机器人、客户关系。

买家支付上下文：支付方式、支付网关、支付交易、保险。

卖家支付上下文：支付方式、支付网关、支付交易、税务。

履约上下文：卖家履约、买家验收、物流。

风控上下文：风控模型、支付风险、账户风险、交易风险。

推荐上下文：个性推荐、趋势推荐、广告推荐。

定价上下文：价格限制、价格推荐、费用计算。

买家上下文：下单、订单、购物车、跨境交易。

卖家上下文：发布管理、一手平台、二手平台、订单。

财务上下文：子账、收入、利润、税收、对账、应收应付。

参考资料

https://zhuanlan.zhihu.com/p/399103071
https://blog.csdn.net/wanghaiping1993/article/details/125493541