【DDD系列-7】领域驱动设计补充解释

1、核心诉求​

首先明确，DDD作为业务架构设计的方法论，其核心诉求是什么？简单来说DDD的核心诉求就是将业务架构映射到系统架构上，帮我们设计出清晰的领域和应用边界(业务范围)，可以很容易地实现架构演进。​

有些开发者试图把DDD与微服务做对比，可以认为DDD是一种架构设计方法，微服务是一种架构风格，DDD并不是架构，而是一种架构设计的方法论。

2、名词解释​

2.1 领域模型​

学习DDD之前，先要了解领域模型。领域模型分为四大类：失血、贫血、充血、涨血，这里的“血”指的是domain object的model/entity/valobj层内容(比如下文举例中的Order)。​

​

• 失血模型：模型只有简单get set 方法，其他所有的行为由服务类完成，这种贫血模型在java中叫POJO，在.NET中叫POCO。​

• 贫血模型：在失血模型基础上聚合了业务领域行为，领域对象模型的变化停留在内存层面，不关心数据持久化。​

• 充血模型：在贫血模型基础上负责数据持久化。充血模型是DDD中推荐使用的。​

• 涨血模型：把和业务逻辑不相关的其他应用逻辑（如授权、事务等）都放到领域模型中，service都不需要，所有的业务逻辑、数据存储都放在一个类中。

2.2 领域、子域、限界上下文​

领域：领域（Domain）就是用来确定范围的，范围即边界，DDD 的领域就是这个边界内要解决的业务问题域，一个领域包含多个子域。一个领域通常就是一个项目。​

引用北理工金旭亮老师的解释，领域中存在问题空间和解决方案空间：问题空间是领域的一部分，是核心域和其他子域的组合；解决方案空间包括一个或者多个限界上下文，即一组特定的软件模型，这是因为限界上下文本身就是一个特定的解决方案。

子域：子域是领域更细粒度的划分，根据重要性与功能将又可以把子域分为三类：核心子域、支撑子域和通用子域。​

• 核心子域:是业务的主要促成因素，一个项目最好只有一个核心域。​

• 支撑子域：是支撑核心子域的，可以有多个，也可以没有。​

• 通用子域：是业务系统的公共部分，可以有多个，也可以没有。

限界上下文：限界上下文是一个语义上的边界，是软件对于问题域的一个特定的、有限的解决方案，用来定义领域的边界，扫清多角色的沟通障碍、统一语言。同时，限界上下文可以用来定义微服务的边界，指导微服务的拆分。一个限界上下文可能被包含在一个子域里，也可能包含多个子域。

限界上下文无论怎么理解，都是比较抽象的，在初始落地DDD实战中，不妨弱化限界上下文，尤其在中小型微服务系统设计时，基本上可以把一个子域当做一个上下文；而在大型的复杂业务项目中，一个限界上下文可能就是一个微服务系统。如果实在分不清限界上下文和子域的关系，那么就把子域当成限界上下文，看下图：

2.3 领域对象、聚合、聚合根、实体、值对象

领域对象分三类：实体、值对象、聚合，都具备领域行为(能力)。参考代码举例见后文，Order和OrderItem都是实体，Address是值对象， OrderAggregateBase是聚合，Order同时是聚合中的聚合根。案例中订单聚合因为业务种类的不同展现出多态属性，所以可以构建一个聚合工厂去管理。

实体(entity)：​

实体有唯一ID标识，有生命周期，有状态，能够被持久化，具有业务逻辑，对应现实业务中的对象。实体一般和主要的业务/领域对象有一个直接的关系。​

​

值对象(value object)：​

值对象的核心是值，与复杂度无关，orderid、ordername、createtime都可以是值对象。值对象是基础类型之延伸，既能封装基础类型，又能约束内部属性间关系，还能拥有着自身的领域行为，与实体的区别是没有唯一身份标识，主要用于描述实体的属性状态。值对象没有生命周期，通过两个值对象的值是否相同区分是否是同一个值对象。​

​

聚合(aggregate): ​

聚合就是一组相关实体和值对象的集合，我们把它作为数据修改和访问的单元。聚合让领域模型中的实体和值对象协同工作，用于保证这些领域对象共同实现业务逻辑时，保证数据一致性，聚合是数据持久化的基本单元。​

在统一语言与业务分析阶段，可借助一系列如事件风暴、四色建模法等分析活动去建立聚合。​

​

聚合根(Aggregate Root)