《领域驱动设计精粹》DDD Domain-Driven Design Distilled -- Vaughn Vernon 读后感

说明

关于设计是否必要或是否负担得起的问题根本都没有问到点上：设计是不可或缺的。除了优秀设计就是糟糕设计，根本不存在“不做设计”一说。 – Douglas Martin

《领域驱动设计精粹》-- Vaughn Vernon 是《领域驱动设计》的浓缩版。讲述了软件工程如何避免造成大泥球的混乱状况。从战略设计、战术设计提供了限界上下文(边界)、子域、上下文映射；聚合、领域事件、事件风暴等思维和工具。

大泥球

经过DDD设计

得到核心领域模型（以保单为例子）

1. 限界上下文

任何事情都要定义边界，因为资源、能力、时间都是有限的，在软件工程领域也一样。

限界上下文是语义和语境上的边界。限界上下文在开始阶段是问题空间的一部分，随着软件模型开始呈现出更深层次以及更清晰的含义时，限界上下文将会迅速转换到解决方案空间。

2. 子域 – 战略设计

子域是整个业务领域的一部分，子域代表的是一个单一的、有逻辑的领域模型。

项目中又三种主要的子域模型：

• 核心域(Core Domain): 一个唯一的、定义明确的领域模型，要对它进行战略投资，并在一个明确的限界上下文中投入大量资源去精心打磨通用语言。它是组织中最重要的项目，因为这将是你与其他竞争者的区别所在，必须把核心域打造成组织的核心竞争力。
• 支撑子域(Supporting Subdomain): 这类建模场景提倡的是“定制开发”，因为找不到现成的解决方案。这类软件模型任非常重要，核心域的成功离不开它。
• 通用子域(Generic Subdomain): 通用紫玉的解决方案可以采购现成的，也可以采用外包的方式。
  

3. 运用上下文映射进行战略设计

敏捷项目管理核心域必须和其它限界上下文进行集成。这种集成关系在DDD中称为上下文映射(Context Mapping).
映射的种类：

1. 合作关系 Partnership：存在于两个团队之间，每个团队各自负责一个限界上下文。两个团队通过互相依赖的一套目标联合起来形成合作关系。一损俱损，一荣俱荣。

2. 共享内核 Shared Kernel：两个限界上下文的交集表示。两个或更多团队之间共享着一个小规模但却通用的模型。团队必须就要共享的模型元素达成一致。

3. 客户–供应商 Customer-Supplier: 描述的是两个限界上下文之间和两个独立团队之间的一种关系：供应商位于上游U，客户位于下游D。支配这种关系的是供应商，因为它必须提供客户需要的东西。

4. 跟随者 Conformist：关系存在于上游团队和下游团队之间，上游团队没有任何动机满足下游团队的具体需求。由于各种原因，下游团队也无法投入资源去翻译上游模型的通用语言来适应自己的特定需求，因此只能顺应上游的模型。

5. 防腐层 Anticorruption Layer：是最具防御型的上下文映射关系，下游团队在其通用语言（模型）和位于它上游的通用语言（模型）之间创建了一个翻译层。

6. 开放性主机服务 Open Host Service: 会定义一套协议或接口，让限界上下文可以被当做一组服务访问。该协议是“开放的”，所有需要与限界上下文进行集成的客户端都可以相对轻松地使用它。通过应用程序编程接口（API）提供的服务都有详细的文档，用起来也很舒服。

7. 已发布语言 Published Language: 是一种有着丰富文档的信息交换语言，可以被许多消费方的限界上下文简单地使用和翻译。需要读写信息的消费者可以把共享语言翻译成自己的语言，反之亦然，而在此过程中它们对集成的正确性充满信心。

8. 各行其道 Separate Way ： 使用各种通用语言来与一个或多个限界上下文集成这样的方式不能产生显著的回报。

9. 大泥球 Big Ball of Mud: 处理大泥球或者要和它进行集成可能面临的严重问题。制造大泥球这种事应该人人避之唯恐不及。
   
   解决大泥球问题的第一步，往往是先增加一个防腐层

3.1 善用上下文，推荐RPC，RESTful，消息机制

4. 运用聚合进行战术设计

1. 聚合：这里展示了两个聚合。它们都是由一个或多个实体组成，其中一个实体被称为聚合根（Aggregate Root）。聚合的组成还可能包含值对象。
2. 实体：一个实体模型就是一个独立的事物。每个实体都拥有一个唯一的标识符，可以将它的个体性和其它类型相同或者不同的实体区分开。
3. 值对象：是对一个不变的概念整体所建立的模型。

4.1 聚合的经验法则

1. 在聚合边界内保护业务规则不变性。

2. 聚合要设计得小巧。

3. 只能通过标识符引用其它聚合。

4. 使用最终一致性更新其它聚合。
   

5. 运用领域事件进行战术设计

领域事件 Domain Event 是一条记录，记录着在限界上下文 Bounded Context 中发生的对业务产生重要影响的事件。领域事件是非常重要的战略设计工具。领域事件往往会在战术设计的过程中被概念化并演变成核心域的组成部分。

事件溯源 Event Sourcing 对所有发生在聚合实例上的领域事件进行持久化，把它们当做对聚合实例变化的记录。存储的是发生在聚合上的所有独立事件，而不是把聚合状态作为一个整体进行持久化。

6. 总结

当使用DDD时，我们的任务是深入学习业务如何运作，然后基于学习的范围建立软件模型。这实际上是一个学习、试验、质疑、再学习和重建模型的过程。我们需要从大量学到的内容中研磨和提炼知识，并创造出能有效满足组织战略需要的设计。我们面临的挑战是如何快速学习。如果不能按时、按预算交付，无论我们的软件可以达到什么样的高度，我们都会失败。但每个人都希望我们在各个方面取得成功。