在领域驱动设计（DDD）中，聚合是模型中的核心构建块，用于管理实体及值对象的生命周期。聚合内的对象之间紧密关联，共同参与业务规则的执行，而聚合之间则相对独立。准确识别和定义聚合边界，是确保系统设计良好、维护成本低以及高内聚低耦合的关键。以下是从实际案例出发，分享的关于聚合边界设计的见解。

实际案例背景

假设我们正在开发一个电子商务平台，该平台支持商品管理、订单处理以及库存管理等功能。其中，订单管理是一个复杂的功能模块，涉及到订单创建、支付、发货等多个步骤。在这个场景下，订单和库存管理是两个分别具有不同业务逻辑的模块，但彼此间又有一定的依赖关系。

识别聚合边界的步骤

1. 领域建模研讨会

   • 通过与领域专家的深入讨论，明确业务流程、关键业务概念及其之间的关系。这对于理解聚合内部元素（实体、值对象、领域事件等）以及确定它们之间如何协作至关重要。

2. 发现聚合候选

   • 在研讨会中，可以通过Ubiquitous Language（通用语言）来捕捉业务概念，识别出可能构成聚合的候选对象。以订单管理系统为例，订单、订单项、客户信息等都可能成为聚合的候选者。

3. 定义聚合边界

   • 一旦确定了聚合的候选者，接下来就是定义它们的边界。这要求清楚地识别聚合内部需要保持一致性的业务规则，并确定哪些操作应该影响哪个聚合。例如，在处理订单支付时，如果支付失败，需要确保订单的状态不会改变，这可能意味着将订单及其状态视为一个聚合。

4. 减少外部依赖

   • 设计聚合时，应确保其尽可能独立，减少对外部服务或聚合的直接调用。例如，在处理订单发货时，可以设计一个发货请求聚合来协调库存检查与实际的发货操作，而非直接在订单聚合里进行库存判断。这样做可以降低系统耦合度，提高系统的可扩展性和灵活性。

示例

假设订单聚合包括订单头（Order Header）和订单项（Order Line），订单头包含客户信息、订单日期等，而订单项包含商品信息及其数量。当创建订单或更改订单项时，这些操作都需要保持订单的整体一致性，即如果其中一个步骤失败，则整个事务应回滚。因此，订单头和订单项作为不可分割的整体被定义为一个聚合。

结论

通过上述步骤，我们可以更有效地识别和定义聚合边界，从而使聚合内部实现高内聚，外部依赖最小化，进而提高整个系统的可维护性和可扩展性。