Question

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

整个系统的核心是“工作顺序” - 几乎每个实体（其中许多实体未在此处显示或部分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更改引用而其他人正在添加返工，则存在某种竞争条件。

Reworks可以改变价格，所以在返工完成之前引用，让我觉得，也许返工应该是它自己的AR - 但是所有的返工都属于工单，你不能在没有先打开/加载的情况下构建返工工作单。

我模型中的所有其他AR在最多3个子实体和几个属性中相对简单，但是工作顺序是一个野兽，我想知道有什么类型的问题我可以通过拥有这个“上帝”对象？？

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

此致亚历

Answer 1

聚合肯定不会像你指出的那么大。聚合中包含的对象应该具有高耦合并共享一些必须始终满足的不变量。聚合之间的不变量最终是一致的。你不能一直依赖它们。我可以想象你可以安全地防止你用两步过程描述的这种不一致。首先检查前提条件。做这些改变。如果一切正常再次检查。如果没有撤消您的更改并重新开始。如果您有更改应触发其他内容使用域事件。有了它们，你可以松散地结合一些过程。

DDD聚合根设计

1 个答案: