3

试图为“制造工厂”软件系统建模...

整个系统的核心是“工单”——几乎每个实体（其中许多没有在这里显示，或者是所讨论的 AR 的一部分）都以某种方式与它相关联。但主要看起来像：

 + WorkOrder_Root
   + TrackingID: Property (UID)
   + DateReceived: Property
   + DateApproved: Property
   + PartName: Property
   + PartNumber: Property

   + Rework: Collection (1:m)

   + SerialLog: Collection (1:m)
   + CeriLog: Collection (1:m)

   + Sequences: Collection (1:m)
   + Dimensions: Collection (1:m)
   + Consumables: Collection (1:m)

   + Quoting: Single 
   + Invoice: Single 
   + Warranty: Single 
   + Certification: Single

这是一个巨大的 AR（不完整——有更多的属性/集合。在过去的几天里阅读了更多的文章和迷你书，我很想知道我是否应该尝试分解成更多的 AR。

http://www.sapiensworks.com/blog/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx

http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx

以上所有集合都是实体的集合，但在工作订单的上下文之外没有任何意义。

没有工单就不能开票，没有工单就不能报价，一切都依赖于工单。

我主要关心的是我理解的潜在并发问题。例如，如果有人正在处理 W/O: 66354 更改报价而其他人正在添加返工，则存在某种竞争条件。

返工可以改变价格，所以在返工完成之前报价，让我想，也许返工应该是它自己的 AR——但所有返工都属于工作订单，如果不先打开/加载 WorkOrder，就无法构建返工。

我在模型中的所有其他 AR 都相对简单，最多 3 个子实体和很少的属性，但工单是野兽，我想知道拥有这个“上帝”对象可能会出现什么类型的问题？？？

编辑：我刚刚阅读了以下内容（http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html）不变量让我三思而后行。如果序列可以更新或更改而无需通知与其关联的工作订单，那么序列是 AR 的候选者？？？序列可能是一个不好的例子，因为对序列的更改确实需要反映在 WorkOrder_Root 中......但仍然......我在正确的道路上吗？让业务规则（而不是逻辑或以数据为中心的组织指导路径？）...

问候，亚历克斯

4

1 回答 1

0

聚合当然不应该像你指出的那么大。聚合中包含的对象应该具有高耦合性，并共享一些必须始终满足的不变量。聚合之间的不变量只是最终一致的。你不能一直相信它们是有效的。我可以想象，您可以通过两步过程安全地防范您所描述的这种不一致。首先检查前置条件。进行更改。再次检查是否一切正常。如果不撤消您的更改并重新开始。如果您有应该触发其他事情的更改，请使用域事件。有了它们，您可以松散地耦合一些过程。

于 2015-03-04T16:08:18.560 回答