Domain driven design 管理聚合边界（DDD）

我在理解如何在DDD中分离骨料时遇到问题。至少，我有一个利益冲突，我不知道如何解决。据我所知，在DDD中，聚合被定义为执行不变量/一致性的事务边界。然而，这导致我的总量巨大且难以维持

我的用例是一个处理电子商务订单的系统。基于业务需求的基本流程如下：

外部系统（购物车）创建一个

订单

，包含发货地址、账单地址和行项目

通过创建

FulfillmentOrder

来完成订单，该订单将发送给外部履行服务提供商

外部履行服务发送货物，并为给定履行订单创建一个或多个

装运。每次装运包括已装运行项目、出发国（此外部服务的仓库所在国）和目的地国（==装运地址国）

为每批

货物创建
发票
，增值税/销售税根据
货物的出发国和目的国计算

这是该域的简化版本。正如你所看到的，有一系列定义明确的步骤，但也有一些纠结。。。。步骤取决于以前步骤和不同实体中的数据。最重要的是：

订单

和

发货

（因此

订单

和

发票

）之间的关系是1:多，而不是1:1

基于上面的聚合定义，我将所描述的用例设计为一个有界上下文（订单处理），

order

是我的聚合根，

Fulfillment order

，

shipping

s和

Invoice

s是由聚合根管理的实体集合

有几个不变量跨越所有多个实体，例如：

• 所有发票的总额不得超过订单总额
• 您不能创建包含非退出订单项目的发票
• 装运项目数量不得超过触发装运的履行订单的数量

将order作为唯一的聚合根允许强制执行这些不变量。但这导致订单总量庞大，难以维持

另一方面，我可以将订单、履行订单、装运和发票分别建模为聚合。这将使每一个聚合更细，更集中。但我失去了执行上述不变量的能力（这显然对业务不利，但也违背了DDD原则）

在领域建模方面是否有指导方针，或者对策略的优缺点进行一些比较

在领域建模方面是否有指导方针，或者对策略的优缺点进行一些比较

一个好的起点是

聚合边界受域动态的驱动：哪些信息必须一起更改。“必须一起改变”有一个时间方面——我们谈论的不是当系统达到平衡时必须保持一致的信息，而是当事情发生变化时必须保持哪些数据关系

为了区分这两种情况，您必须非常注意以下问题：如果此报告中的信息过时，企业的成本是多少

您不能创建包含非退出订单项目的发票

为什么不呢？发生这种情况时，企业的成本是多少

时间上的微秒差异不应该对核心业务行为产生影响

---

在建模时，您必须小心，以避免假设信息会立即在系统中传播。特别是在接触真实世界的系统中，信息以有限的速度传播，业务流程包括补偿协议。

谢谢。我觉得我对聚合的理解是有缺陷的：我认为不变量的强制执行（在任何时候，无论发生什么）是主要特征。您将重点放在时间方面（在运输过程中强制执行不变量），而装运、发票等之间的最终一致性则通过其他方式（业务流程）强制执行。在我上面的示例中，如果存在检查最终不一致性的业务流程，您确实可以将订单、履行订单、装运和发票建模为单独的聚合，分别补偿这些不一致性。