[DDD]领域驱动设计 基础篇

[supergem3000]

领域驱动设计

DDD包括战略设计和战术设计两个部分。 战略设计主要从业务角度出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。 战术设计则从技术角度出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

阅读材料：DDD领域驱动设计落地实践系列：战略设计和战术设计_Java_慕枫技术笔记_InfoQ写作社区

领域、子域

领域，就是字面意思，“领域是从事一种专门活动或事业的范围、部类或部门”。范围即边界。 领域可以进一步划分为子领域。每个子域对应一个更小的问题域或更小的业务范围。

核心域、通用域、支撑域

子域可以根据自身重要程度划分为三类子域：核心域、通用域、支撑域。 决定产品竞争力的是核心域；没有太多个性化需求、被多个子域使用的通用功能子域是通用域（举例：认证、授权）；必需的但不包含竞争力的功能、也不包含通用功能的是支撑域（举例：数据代码类、数据字典）。 核心域、支撑域和通用域的主要目标是：通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

通用语言、限界上下文

通用语言：团队共识的交流语言 限界上下文：通用语言、领域对象的上下文环境，保证领域内的术语没有二义性。

举例：“能穿多少穿多少”是穿多还是穿少？如果提供了环境寒冬或夏日，这句话的含义就明确了。

实体和值对象

实体，就是通常理解的含义

• 业务形态：领域模型中实体是多个属性、操作或行为的载体。实体和值对象是组成领域模型的基础单元。
• 代码形态：实体类，通常是充血模型。
• 运行形态：领域对象（DO）的形式，有唯一ID
• 数据库形态：DDD是先构建领域模型，针对业务场景构建实体对象和行为，再将实体对象映射到数据库持久化对象。一个实体可能对应0个、1个、多个持久化对象，大多数是一对一。某些场景如计算后的折扣实体是运行态实体，不需要持久化 值对象，将不同的相关属性组合成一个概念整体
• 业务形态：包含若干属性，与实体一起构成聚合。基本不包含业务逻辑
• 代码形态：如果值对象是单一属性，则直接定义为实体类的属性；如果值对象是属性集合，则设计成Class，这样的值对象没有ID，被实体整体引用。
• 运行形态：属性嵌入实体或序列化大对象。 举例将地址嵌入人员 属性嵌入：id name age gender province city county street 序列化大对象：id name age gender address(序列化JSON串)
• 数据库形态： 基于上面人员+地址场景。一是把地址值所有属性放到人员实体表中；二是创建人员和地址两个实体两张表。方案一会破坏“地址”的业务含义和概念完整性，方案二增加了不必要的实体和表。怎么办？ 领域建模时，把地址作为值对象，人员作为实体。数据建模时，把地址属性值嵌入人员实体数据表中。既兼顾业务含义表达，又不增加数据库复杂度。 优先做领域建模，弱化数据库作用。违反数据库设计原则也问题不大。
• 优势和局限： 值对象采用序列化大对象，降低数据库复杂度，但无法满足基于值对象的快速查询。 值对象采用属性嵌入，提升了数据库性能，但实体引用值对象过多会导致实体堆积一堆缺乏概念完整性的属性，操作起来不方便。

  聚合和聚合根

  领域内实体和值对象好比个体，能让实体和值对象协同工作的组织就是聚合，确保领域对象在实现共同的业务逻辑时，实现数据的持久化。 聚合由逻辑紧密关联的实体和值对象组合而成，是数据修改和持久化的基本单元。 聚合有一个聚合根和上下文边界。 聚合根避免数据模型缺少统一业务规则控制，导致聚合、实体之间数据不一致。 聚合根是聚合的负责人，也成为根实体。负责协调实体和值对象按个规则协调完成逻辑。 聚合之间聚合根是对外接口人。聚合之间通过聚合根ID关联引用，要访问其他聚合的实体，要通过聚合根导航到聚合内部实体。