DDD核心知识体系
什么是DDD
DDD 是一种 架构设计方法，DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
DDD的关键概念
-
领域：业务范围
-
子域：领域可以划分为不同的子域，子域可以进一步划分为更小的子域。
子域可以分为 核心域、通用域、支撑域。
-
通用语言：项目团队沟通和协调形成的统一语言
-
限界上下文：确定语义所在的领域边界，限界上下文是微服务设计和拆分的主要依据
-
实体：实体一般对应业务对象，它具有业务属性和业务行为。状态可变，依附于聚合根，生命周期由聚合根管理
-
值对象：值对象主要是属性集合，对实体的状态和特征行为进行描述
-
聚合：聚合就是由业务和逻辑紧密关联的实体和值对象组合而成。
-
聚合根：聚合之间通过聚合根关联引用，如果需要访问其他的聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内部实体。聚合根也是实体，有实体的特点。
业务领域模型转为程序的两种设计思路
贫血模型
在软件设计中，有很多 POJO 对象，它们除了有一堆 get/set 方法，集合没有任何业务逻辑，即领域对象中的属性与业务行为拆分开。
优点
- 更契合 MCV 三层架构
- 实现简单
缺点
- 表达力不足，领域对象无法很好的表达业务行为
- 逻辑分散，业务行为分散在 service 中，复杂的业务实现会导致服务臃肿
充血模型
领域对象中包含具体的业务操作
优点
- 契合 DDD 的设计理念，领域对象直接表达逻辑的实体
- 可读性高，业务逻辑都体现在领域对象中
缺点
-
违背单一职责原则，领域对象可能承担数据存储和业务行为，职责不够单一
-
实现复杂
DDD 分层架构
传统的四层架构
基础层被其他层依赖，基础层更像是核心层，但实际上领域层才是核心层。
DDD的优化后的四层结构
领域层作为核心层
各层级的职责
其中应用层应该是很薄的一层，理论上不应该有业务规则和逻辑。应用层也是微服务之间交互的通道
防腐层（Anticorruption Layer, ACL）
用于隔离核心领域模型与外部系统或上下文之间的耦合。它通过引入一个独立的转换层，将外部系统的数据或行为与核心领域模型进行解耦，防止外部系统的复杂性或变化对核心领域模型造成侵蚀或影响。
资料
- 网页链接
- 领域驱动设计DDD和CQRS落地
- 极客时间-DDD 实战课
- book
- 实现领域驱动设计
- 领域驱动设计
