领域驱动设计（DDD）是一种软件设计方法，专注于在代码中体现业务的理解。通常，干净架构与领域驱动设计配合得相当不错，这主要是因为分层分离，其中领域位于中心，这意味着领域层不依赖任何外部因素。

1. 域
我们正在解决的业务问题的领域。一个好的域模型能够捕捉到核心的业务规则和行为，同时保持独立于基础设施的考虑。因此，使用与领域/业务团队相同的语言很重要，确保开发人员（技术人员）和领域专家（非技术人员）保持一致。这就是所说的通用语言。

2. 实体和对象值

• 实体是通过其唯一的标识来定义的，而不是通过其属性来定义。即使它们的属性发生变化，它们仍然是同一个实体。
  例如，一个 Customer 是一个实体，因为它有唯一标识（如客户ID或电子邮件地址）来区分它与其他客户。即使客户的姓名或其他信息发生变化，只要标识（如ID或电子邮件地址）不变，该客户仍为同一个客户。

• 值对象（VO）则是通过其属性来定义，不具备唯一标识。两个具有相同属性的值对象被视为相同。
  例如，Address 可以是一个值对象，两个相同的地址（相同的街道、市和邮政编码）可以互换，除了属性外，没有其他唯一标识。

在一个组织里，结构可以包含很多实体，每个实体都有自己的价值对象。

3. 聚合体和聚合根

• 聚合是一组相关的领域对象，应该被视为一个单一的单元（请参见下面的图片，以更好地理解）。这确保了一致性和封装了业务逻辑。
• 聚合根是主要实体对象，它控制对聚合内其他对象的访问。聚合根始终是实体，绝不会是值对象。

这是一张教程图，看起来挺有意思的。

聚合之间主要通过领域事件来交流。当一个聚合中的某个变化需要影响到另一个聚合时，这个聚合就会发送一个事件，其他聚合会监听并据此作出响应。

更真实的聚合的例子。比如在图书馆系统中，一个图书馆可以管理多本书，每本书都有自己的一些属性，比如书名、作者以及在图书馆中的位置。

如需查看图片，请点击链接查看。

• 图书馆（聚合根，即系统中用于管理相关实体的数据结构）

图书馆是一个实体，因为它有一个独特的身份标识（libraryId）。它代表系统内的书籍集合。它也是聚合根，这意味着它控制对聚合内其他实体的访问，在这种情况下是书籍实体。

• 书（实体项）

这本书有独特的身份标识（ISBN），因为它代表了图书馆藏书中的一本特定的书。它是图书馆的一部分，它的属性由图书馆管理。

• 书本信息，位置（VO）

它们之所以是值对象，是因为它们没有特定的身份，仅仅由其属性定义。

4. 域服务

有时候，业务逻辑有时并不适合直接关联到某个实体或值对象。遇到这种情况时，我们会利用领域服务来封装这种逻辑。

5. 领域事件

领域事件捕获了业务领域中重要的事件。例如，当一笔支付完成时，可以发布比如PaymentCompleted事件，从而触发相应的操作，例如发送电子邮件通知。

6. 限定的上下文.

这个概念有点抽象。有界上下文代表有自己的模型和逻辑的子领域，就像个“边界”，把系统的一部分和其他部分隔开。例如，比如说，在网上商店里，你可能会有管理订单的有界上下文和处理支付的有界上下文，每个有界上下文都有自己的模型和逻辑。不要把聚合和有界上下文搞混，聚合是存在于有界上下文内的较小的群体，但有界上下文帮助将整个系统中的不同业务领域区分开来。

DDD不仅仅是为了结构代码，它是一种思维方式的转变，强调与领域专家进行深度合作，并将业务逻辑以一种清晰且易于维护的方式进行建模。