As a quick break down I will explain my current application. It’s a work order management system for an aerospace components services and overhaul. We are contracted work airlines looking for specialized repairs for certain components. There is an existing (new) system called an RPI management system, which essentially allows our engineers to build FAA/DOT approved repair documents.
The work order system communicates with this RPI system for each work order that is created when we receive a part. The RPI essentially provides a template of possible repairs particular for a make/model/part number - the work order system clones the RPI and inspection checks off the steps (ie: sequences) required to repair the part to our standards.
That being said, there are probably close to 2 dozen tables which all associate with a work order - which are primarily distinguished via an ID number (auto-increment).
So every work order created can/may have the following associated entities:
- Sequences (1:m)
- Consumables (1:m)
- Shipping (1:1)
- Quotesheet line items (1:m)
- Reworks [additional|reprocess] (1:m)
- Certifications (1:1)
- Non-conformances (1:m)
We are using extJS for a real-time AJAX powered interface. The primary listbox displays all available work orders, upon selecting a work order all other view/panes/lists are populated with the appropriate records.
Each of the above entities typically have their own MVC component/directory.
— Off Topic —
I have been reading up on DDD and MDA the last few years and more importantly in the last few weeks. With the exception to Eric Evans book I think I have read/found every conceivable source on the subject via Google I figure now it’s time to ask public questions and read the replies. 
I am trying to apply the appropriate vocabulary and structure to my rich domain model and would like any input.
Work Order is the primary unit of functionality (ie: root object) of this system everything else is secondary (ie: aggregate child).
The problem is from what I have read DDD domain models zealously protect child aggregates and access to them is done through the root object.
You cannot have a consumable without an associated work order but because of the real-time nature and sophistication of the interface, accessing, adding, deleting a consumable from a work order using the work order root object would make no sense at all. The consumable list is powered by it’s own MVC components/directory.
So while each of these components is a distinct module, they are almost ALL connected to the work order ID/number and cannot/should not exist without a valid W/O ID#
The work order root object does have a supplementary table used for logging status changes to the work order. This was easily implemented in the work order model and didn’t feel to hack.
Pardon the lack of clarity with this question but this is one part brain dump and one part question - looking for opinions or input on the subject.
Given that each ‘module’ such as consumables, work orders, certifications, etc have their own MVC components (single controller.php and model.php) and the views are handled client side via extJS.
I guess particularly, my model.php files are getting quite large in many cases (especially work order). The data access is done through a generic table data gateway object - so the model is cleared of SQL. Validation logic and business rules are all that remain except in cases such as adding/removing a work order - in which case all of it’s associated entities must be added or removed as well.
This does not make sense in the work order model (although that is where it’s at) any more than having it in consumables delete. Is this where a DDD service would come in handy?
I have tried implementing something of an event listener or AOP approach, where I externalize this complex operation as an aspect (probably best defined a hook/event) so it’s externalized from the work order entity and everything else. Was not a huge fan of this solution and hence moved the code back into work order.
I am seeking a standard way to further decompose the model to eliminate clutter and hopefully focus strictly on business rules for clarity. I have a experimental implementation in place to remove validation from the model layer (which I refer to as domain model per module) and perform pre-invocation similar to aspects or pre-hook might function. As for formatting the raw data coming from a TDG SELECT this is typically done in the model method context as well which also clutters the area of interest.
Cheers,
Alex