DDD 学习笔记

1 概念

1.1 领域

领域，指的特定行业或者场景下的业务逻辑。

领域就是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因。

1.2 通用语言，统一语言

通过团队交流达成共识的，能沟简单、清晰、准确描述业务涵义和规则的语言。

1.3 限界上下文（Bounded Context）

• 限界：领域的边界。
• 上下文：语义环境。

电商领域的商品，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成的货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界。

限界上下文是一个非常有用的工具，限界上下文可以帮助我们识别出业务的边界，并做适当的拆分。

领域边界就是通过限界上下文来定义的。

1.4 实体

实体对象表示的是具有一定生命周期并且拥有全局唯一标识(ID)的对象。

实体的代码形态

在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。在 DDD 里，这些实体类通常采用充血模型。与这个实体相关的所有业务逻辑都在实体类的方法中实现。

实体的运行形态

每个实体对象都有唯一的 ID。可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的ID，它们依然是同一个实体。

1.5 值对象

表示用于起描述性作用的，没有唯一标识的对象。

值对象是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。

1.6 聚合（Aggregate）

聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

1.7 聚合根（Aggregate Root）

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

2 实践

2.1 基于业务的分包

早年的Java分包方式通常是基于技术的，比如与domain包平级的有controller包、service包和infrastructure包等。这种方式当前并不被行业所推崇，而是应该首先基于业务分包。比如，在订单示例项目中，有两个重要的领域对象Order和Product（在DDD中称为聚合根），所有的业务都围绕它们展开，因此分别创建order包和product包，再分别在包下创建与之相关的各个子包。此时的order包如下：

├── order
│   ├── OrderApplicationService.java
│   ├── OrderController.java
│   ├── OrderNotFoundException.java
│   ├── OrderRepository.java
│   ├── OrderService.java
│   └── model
│       ├── Order.java
│       ├── OrderFactory.java
│       ├── OrderId.java
│       ├── OrderItem.java
│       └── OrderStatus.java

https://insights.thoughtworks.cn/backend-development-iteration0/

创建聚合根 - 工厂(Factory)模式

程序中往往存在多个构造函数用于不同的场景，而为了将业务上的创建与技术上的创建区别开来，我们引入了 create() 方法用于表示业务上的创建过程。

Command 对象

Command即命令的意思，也即写操作表示的是外部向领域模型发起的一次命令操作。事实上，从技术上讲，Command对象只是一种类型的DTO对象，它封装了客户端发过来的请求数据。

统一使用Command对象还有个好处是，我们通过查找所有后缀为 Command 的对象，便可以概览性地了解软件系统向外提供的业务功能。

思考、讨论

结合自己所在项目的业务情况，尝试给业务做一个领域模型分析。可以和项目组人员讨论，使用 ”事件风暴“ 这类工作坊的方式完成领域模型、统一语言、边界上下文。

实体与对象的区别？

结合自己所在项目的某个业务场景，分析出哪些是聚合？

聚合根的理解，与实体的区别？