Building a complex manufacturing management system. I have dozens of entities, some which seem to make sense as child aggregates others clearly do not.
Allow me to list the various entities, in a sort of order of importance:
- WorkOrder
- Quote
- Invoice
- Warranty
- Certification
- NonConformance
- Shipping
- SerialLog
- CeriLog
- Sequence
- Rework
- Consumable
- RepairLineItem
These are only some but most relevant to my question.
All of them (with the exception being invoice) only exist with relation to a Workorder (TrackingID).
A workorder can exist without having any NonConformance, Warranty, etc with the ONLY exception being Sequence - a workorder must have at least ONE sequence.
A rework will aggregate it's own Sequence collection, sequences which are created after the fact MUST belong to a rework.
A Workorder may exist without a Quote, however a quote requires access to at least Consumable and RepairLineItem (used to tally total of work scope)
Initially I had all of these entities modeled as aggregates of the Workorder/AR but this screamed bad design, so I have begun making each their own aggregate roots with their own repository. By doing this though, I have now lost the ability to enforce constraints.
For example, when a work order is created it has a fixed number of sequences, dictated by a approved manual. Those sequences can be checked on or off by an inspector. That work order traveler is then printed and the work order is locked from change. Occasionally new sequences need to be added, to correct a mistake or because the original manual was missing a critical step - this is when a rework is created and new sequences added to the work order.
When those sequences are added, the workorder aggregate root needs to be informed, in order to analyze the change, and possibly re-schedule the estimated completion time.
Likewise, a work order has a set list of repair items or consumables (the latter of which can be added to at anytime after inspection). If the quantity of either of those entities change, that must percolate back to the work order which must notify the quote aggregate, so the total cost can be updated and appropriate parties notified VIA email.
Obviously having a monolithic AR would not make sense (especially performance standpoint -- this is implemented as a AJAX web-based app). The repository for work order would be convoluted with methods like:
selectAllConsumablesForWorkOrder()
selectAllRepairItemsForWorkOrder()
selectAllCertificationsForWorkOrder()
...
My question is, given the above scenario and requirements, how do I use smaller aggregate roots all whilst enforce those invariant rules? If everything was encapsulated by the WorkOrder/AR I can see how I could easily enforce the above requirements.
My understanding of DDD is far from perfect so please be gentle :)
It's possible I have the wrong impression of what AR's are all about but most articles I have read seem to suggest this, using a Product and multiple line item example. Which effectively is what this work order is, but each line item is possibly shared by other aggregates...
Any experience or input appreciated
Regards, Alex
