1
votes

Everything I have read thus far on DDD implies only entities which encapsulate other entities are root aggregates.

What about in situations like:

WorkOrder
 - idManufacturer
 - WONumber
 - Description

Manufacturer
 - idSelf
 - Name

WorkOrder references Manufacturer but would not be a child of WorkOrder as other entities might reference WorkOrder, in this case I would consider both Root entities, but the Manufacturer is not an aggregate...

Is this correct?

3
What is your bounded context and can the user DIRECTLY interact with Manufacturer?Aaron Hawkins
Maybe my post will help you understand better how to identify aggregates and aggregates roots (AR). Btw AR is unrelated to the notion of childrenMikeSW

3 Answers

1
votes

I once had a lightbulb moment with DDD when someone told me that entities with no children can be though of as aggregate roots.

Particularly when someone says "persist only your aggregate roots".

In your example, your aggregate roots are WorkOrder and Manufacturer. You'd have a repository for WorkOrder and one for Manufacturer.

1
votes

In fact, you will mostly have aggregates with value objects only. ARs with child entites are rare. Read red book (Implementing DDD Vaughn Vernon), there is described rule of small aggregates.

0
votes

The job of an aggregate root is to encapsulate and enforce invariants. It may consist of other objects but they are all interacted with through the AR. The important thing to remember about an aggregate, is that is should be independent of your chosen persistence mechanism. The majority of your aggregates should have no dependencies at all!

I may be mistaken but it looks like the idManufacturer is a foreign key. This would suggest (not always the case) it is not encapsulated. The thing that took me a while to get my head around was that the fields within an aggregate are private. This raises the question of how you save it's state and how you get data to put on the UI. There are lots of ways to that. My preferred approach is to use Event Sourcing and CQRS. I can then build out UI's from the events that my aggregates produce. I can also persist those events and use them to rebuild my aggregate.

I've gone into a lot more depth on my blog, you may want to take a look at How to Build an Aggregate Root! . You may also find helpful a post on building a master details screen when using CQRS and Event sourcing, that can be found here!

I hope that helps.