DDD Aggregate root design

Question

Trying to model an 'manufacturing plant' software system...

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:

 + 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

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.

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

All the above collections are collection of entities but none of which make sense outside the context of the work order.

You cannot invoice without a work order, you cannot quote without a work order, everything relies on a work order.

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.

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.

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???

EDIT: I just read through the following (http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html) 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?)...

Regards, Alex

Just found this article: lostechies.com/jimmybogard/2010/02/24/… ut beyond validation are the invariants of an entity. Invariants are the essence of what it means for an entity to be an entity. We may ask our customers, can a Person be a Person (in our system) without a BirthDate? In this case almost all entities (warranty, certification, invoice, quote, etc) are not invariants and deserve their own AR? A workorder can exist without a quote (it's incomplete but it does happen). — Alex.Barylski
To add to note above, a workorder cannot be invoiced without a quote -- so how would this be modeled as an AR? You cannot create a quote without a workorder -- my head is spinning in circles now :) — Alex.Barylski
Finally...if Quoting is not an child entity of WorkOrder -- how do we ensure a valid workorder is associated with it? Is this done in the validation of the Quoting save method??? — Alex.Barylski
If the invariants you're protecting now could be replaced with eventual consistency(refer to you domain experts), then the aggregate could be decomposite. — Yugang Zhou
@Alex.Barylski any updates on how you went about implementing this ? Would like to know your approach... — Sudarshan

Holger Thiemann Holger Thiemann · Accepted Answer · 2015-03-04T16:08:18

Aggregates should certainly not be as big as you pointed out. The objects contained in an aggregate should have high coupling and share some invariants that must be met all the time. Invariants between aggregates are only eventually consistent. You can not rely on them as valid all the time. I could imagine that you can safely guard against such inconsistencies as you described with a 2 step process. First check the preconditions. Do the changes. Check again if everything is fine. If not undo your changes and start over again. If you have changes that should trigger something else use domain events. With them you can loosely couple some processes.

DDD Aggregate root design

1 Answers