### 聚合 vs 领域服务 vs 仓储 —— 对比一览

| 特性         | **聚合（Aggregate）**                                        | **领域服务（Domain Service）**                               | **仓储（Repository）**                                       |
| ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **本质**     | 相关实体和值对象的**组合**，以“聚合根”为唯一访问入口         | 无状态的业务逻辑单元，封装**跨实体 / 跨聚合**规则            | 抽象的数据访问接口，隐藏底层存储细节，为聚合**提供持久化能力** |
| **状态**     | **有状态**——内部维护数据与不变式                             | **无状态**——仅暴露行为                                       | **无业务状态**；实现层可能有缓存，但对外看作无状态           |
| **职责**     | 1. 内部一致性2. 定义事务边界3. 提供领域行为（`order.pay()` 等） | 1. 承载跨实体规则2. 协调多个聚合完成业务动作                 | 1. 加载 / 保存聚合根2. 把 PO ↔️ Entity 映射3. 屏蔽 SQL/ORM/缓存等技术细节 |
| **边界**     | *聚合边界*：内部操作要么全部成功要么全部失败                 | 无一致性边界，仅调用聚合或仓储                               | *持久化边界*：一次操作针对一个聚合；不负责业务事务（由应用层控制） |
| **典型用法** | `Order.addItem()`,`Order.cancel()`                           | `PricingService.calculate(...)`,`InventoryService.reserveStock(...)` | `orderRepository.findById(id)`,`orderRepository.save(order)` |

#### 快速记忆

- **聚合**：有数据 + 行为，是“业务发动机”
- **领域服务**：无数据，专管“发动机之间的协作”
- **仓储**：无业务规则，只负责把“发动机”**存取**到持久化介质

这样三者的定位就清晰了：

> “**聚合**管状态，**领域服务**管跨聚合业务，**仓储**管存取。”
