建立复杂的制造管理系统。我有几十个实体，其中一些似乎有意义，因为儿童聚合其他人显然没有。
请允许我按重要性顺序列出各种实体：
这些只是一些但与我的问题最相关。
所有这些（发票除外）仅与工作订单（TrackingID）相关。
工作订单可以在没有任何不合规，保修等的情况下存在，唯一的例外是序列 - 工作订单必须至少有一个序列。
返工将聚合它自己的序列集合，这些序列是在事实必须属于返工之后创建的。
工作订单可能不存在报价，但报价需要至少访问耗材和RepairLineItem（用于统计工作范围）
最初，我将所有这些实体建模为Workorder / AR的聚合，但这是一个尖叫的糟糕设计，所以我开始用他们自己的存储库创建每个自己的聚合根。通过这样做，我现在已经失去了强制执行约束的能力。
例如，创建工作单时，它具有固定数量的序列，由批准的手册指定。检查员可以检查或关闭这些序列。然后打印该工单旅行者并锁定工作订单以防止更改。偶尔需要添加新序列，以纠正错误或因为原始手册缺少关键步骤 - 这是在创建返工并将新序列添加到工作单时。
当添加这些序列时，需要通知工作订单聚合根，以便分析更改，并可能重新安排估计的完成时间。
同样，工单有一套修理项目或消耗品（后者可在检查后的任何时间添加）。如果这些实体中的任何一个的数量发生变化，那必须渗透回必须通知报价汇总的工单，这样可以更新总成本，并通过威盛电子邮件通知相关方。
显然拥有单片AR是没有意义的（尤其是性能观点 - 这是作为基于AJAX网络的应用程序实现的）。工作订单的存储库将使用以下方法进行复杂处理：
selectAllConsumablesForWorkOrder()
selectAllRepairItemsForWorkOrder()
selectAllCertificationsForWorkOrder()
...
我的问题是，鉴于上述场景和要求，如何在执行这些不变规则的同时使用较小的聚合根？如果所有内容都由WorkOrder / AR封装，我可以看到如何轻松实施上述要求。
我对DDD的理解远非完美，所以请保持温和：）
我可能对AR的所有内容有错误的印象，但我读过的大多数文章似乎建议使用产品和多个订单项示例。这个工单有效，但每个订单项可能由其他聚合共享......
任何经验或投入赞赏
此致 亚历
答案 0 :(得分：1)
某些ddd标记的问题难以回答，因为它们是特定于域的。老实说，我并不完全理解workorder域，但一般来说，如果你想使用较小的聚合，你可以考虑使用DomainEvents。
您可以发布一个DomainEvent，它表示在有界上下文中实际发生了某些内容，例如
返工时，发布 ReworkCreatedEvent ，其中包含 TrackingId 和序列（可能是值对象） aggregate）已创建。 ReworkCreatedEventHandler 负责更新相应的 WorkOrder （聚合），然后发布 WorkOrderCompletionTimeReestimatedEvent 以通知以下步骤。
可以同步或异步处理事件取决于不变量。您需要与您的域专家讨论它们。
我认为使用较小的聚合是一个昂贵的决定，您需要优秀的领域专家和一些不错的基础设施。