title: DDD Aggregate root design
body: <p>Trying to model an 'manufacturing plant' software system...</p>
  
  <p>At the core of the entire system is the "workorder" -- almost every entity (many of those are not shown here or part of the AR in question) is somehow connected to it. Primarily however it looks like:</p>
  
  <pre><code> + 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 
  </code></pre>
  
  <p>This is a massive AR (incomplete -- there are more properties/collections. Having read several more articles and mini-books in the last few days I am seriously wondering whether I should try and decompose into more AR.</p>
  
  <p><a href="http://www.sapiensworks.com/blog/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx" rel="nofollow">http://www.sapiensworks.com/blog/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx</a></p>
  
  <p><a href="http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx" rel="nofollow">http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx</a></p>
  
  <p>All the above collections are collection of entities but none of which make sense outside the context of the work order.</p>
  
  <p>You cannot invoice without a work order, you cannot quote without a work order, everything relies on a work order.</p>
  
  <p>My primary concern is what I understand to be potential concurrency issues. For example, if someone is working on W/O: 66354 changing the quote and someone else is adding a rework, there exists something of a race condition.</p>
  
  <p>Reworks can change the price, so quoting before a rework has completed, makes me think, perhaps rework should be it's own AR -- but all reworks belong to a work order, you cannot construct a rework without first opening/loading a WorkOrder.</p>
  
  <p>All my other AR's in the model are relatively simple at most 3 child entities and few properties, but the work order is a beast and i'm wonder what type of issues I might expect by having this "God" object???</p>
  
  <blockquote>
    <p>EDIT: I just read through the following
    (<a href="http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html" rel="nofollow">http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html</a>)
    Invariants made me think twice. If a sequence can be updated or
    changed without needing to inform the work order in which it is
    associated, then sequences is a candidate for AR???  Sequences may be
    a bad example as changes to the sequences do need to be reflected in
    the WorkOrder_Root...but still...am I on the right path here? Letting
    the business rules (rather than logical or data-centric organization
    guide the path?)...</p>
  </blockquote>
  
  <p>Regards,
  Alex</p>