20 lines
2.1 KiB
Markdown
20 lines
2.1 KiB
Markdown
### 聚合 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)` |
|
||
|
||
#### 快速记忆
|
||
|
||
- **聚合**：有数据 + 行为，是“业务发动机”
|
||
- **领域服务**：无数据，专管“发动机之间的协作”
|
||
- **仓储**：无业务规则，只负责把“发动机”**存取**到持久化介质
|
||
|
||
这样三者的定位就清晰了：
|
||
|
||
> “**聚合**管状态，**领域服务**管跨聚合业务，**仓储**管存取。”
|