DDD（Domain Driving Design）领域驱动开发

1、微服务设计为什么选择DDD

1、架构对比

• 单机架构：数据驱动架构

• 集中式架构：面向对象的方式（三层架构）

• 分布式微服务架构：应用之间解藕，解决单体用扩展性和弹性伸缩能力不足问题

2、微服务的问题

• 微服务粒度

• 怎样拆分

• 边界是什么

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

3、战略设计（业务层面-业务架构）

建立领域模型、划分领域边界，从业务的视角来划分微服务边界（收敛的过程）

• 实体
• 命令
• 事件

领域模型：指导微服务的设计和拆分。事件风暴是建立领域模型的主要的方法，

事件风暴：

• 从发散到收敛的一整个过程
• 采用方法：用例分析、场景分析、用户旅程分析
• 产出：产出实体、命令、事件等领域对象，将领域对象从不同维度进行聚类形成聚合、限界上下文等边界，建立领域模型

逻辑边界、物理边界

4、战术设计（技术层面-系统架构）：

侧重于领域模型的实现，侧重于代码逻辑的设计和实现

实现层面

• 逻辑边界
• 物理边界

5、DDD和微服务

DDD：主要关注从业务领域视角划分领域边界，通过业务抽象建立领域模型，维持业务和代码层面的一致性

微服务：主要是从技术层面，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署

总结：DDD是一种架构设计方法，微服务是一种架构风格。DDD是一种从业务视角去分离系统建设复杂度的手段，应用于微服务中，DDD解决微服务设计过程中边界难以界定的问题。

2、领域、子域、核心域、通用域、支撑域

• 领域：指一种特定的范围。用于限制业务边界和范围的。

• 子域：对应更小的业务范围

  • 核心域：决定产品和公司核心竞争力的子域，业务成功的主要因素和公司的核心竞争力
  • 通用域：需要用到的通用系统
  • 支撑域：具有企业特性，但不具有通用性

复杂问题拆解细分，建立子域

• 研究对象
• 研究对象细分

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。通过领域划分，区分不同子域在公司内的不同功能属性和重要性（核心域、通用域、支撑域），从而公司可对不同子域采取不同的资源投入和建设策略

3、限界上下文

• 通用语言定义上下文含义，限界上下文则定义领域边界

• 限界上下文就是用来细分领域，从而定义通用语言所在的边界

• 一个限界上下文理论上就可以设计为一个微服务

4、实体和值对象：从领域模型的基础单元看系统设计

DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变。实体和值对象是微服务底层的最基础的对象。DDD 提倡从领域模型设计出发，而不是先设计数据模型。

实体对象（业务层面）

• 实体和值对象是组成领域模型的基础单元。

• 在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法

值对象（数据层面）

在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。

实体对象VS值对象

• 实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。

总结：值对象的引入，保留了业务层面的含义，减少了实体数量，并且在数据建模层面，简化了数据库设计

5、怎样设计聚合？聚合和聚合根

• 聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

• 聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑

聚合根解决了什么问题？

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题

聚合根承担的角色是什么？

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

如何判断一个实体是否是聚合根?

可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体？

6、领域事件

用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。领域事件来驱动业务的流转

7、中台