I have Category and Product entities. The relationship between the two is one to many. Since, Category is aggregate root I think I should only make a single repository ICategoryRepository which should also handle products.
Ideas?
I'm without my copy of Domain Driven Design by Evans at the moment, which is where I'd turn for the definitive answer, but this reference at dddstepbystep states that:
Within an Aggregate there is an
Aggregate Root. The Aggregate Root is
the parent Entity to all other
Entities and Value Objects within the
Aggregate.
A Repository operates upon an
Aggregate Root
So yes, going by this definition, your Category Repository should be responsibly for persisting all entities within the Category aggregate.
That said though, my question from my comment still stands - are you sure that Category really is a useful aggregate root? The fact that you are asking this question about persisting products indicates that you often consider them seperate from their Category, or at least would like to be able to deal with some product aside from their category.
Related
I’m trying to understand Aggregate root in domain driven design. can aggregate root have deeply nested entity ? Like an entity within a entity or the aggregate roots are supposed to have shallow collections of entities ?
Thanks,
Ravi
An "aggregate root" will always be a single entity.
An "aggregate" may have many entities in it (of which exactly one plays the role of root). The entity graph within the aggregate can be deep.
Most aggregates have few entities; concurrent edits of two different aggregates is relatively straightforward to manage. Concurrent edits of a single aggregate means conflict. So we are normally trying to scale our aggregates so that the conflicts are necessary -- lots of incidental unnecessary conflict may indicate that our aggregate boundaries could be improved.
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?
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.
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.
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.
i've been assigned a quite simple project as an exam and i had the idea to develop it using the Domain Driven Design.
Many of you might say that the application is so simple that going with repositories and UoW is just a waste of time, and you probably be correct but i think of it as an opportunity to learn something more.
The application is a "Flight tickets" system and from the following image you could probably well guess it's functionality.
The thing is that i am not sure if i am correctly seperating the aggregates and their roots.
EDIT:
I presented the data model so anyone can spot the whole functionality easily.
The thing is that from an employe perspective the flight as "Rad" said encapsulates the whole functionality and is the aggregate root.
However from an admin perspective, flights are none his bussiness.
He just want to update or add new planes-companies, etc..
So then there is a new aggregate root which is the Airplane which encapsulates the Airplane seats(Entity), the seatType(value object) and the company(Entity) as a new aggregate.
This tends to confuses me as i have an aggregate root(Airplane) inside another aggregate(Flight Aggregate).
Since the aggregate root is consider to be the "CORE" entity which without it the other entities inside it will not make any sense without it, i am thinking about Company. And i conclude that company makes sense without the airplane.
To explain more i think of the scenario where the admin want to just insert a new Company, or want to first load a company and then its airplanes.
DDD principles say that any entities inside the aggregate may only be loaded from the root itself.
So here is the confusion.
Mmm, where is the Aggregate and Aggregate roots here ? This is only Data Model... Not Domain Model.
Aggregate is a cluster of items (Domain Object) that are gathered together, and Aggregate Root are the entity root... (If you consider the Flight Aggregate encapsulates Seats, Location... The Aggregate Root should be Flight entity).
[Edit]
You have to ignore the persistent. In your app you can have many aggregate it depends in your Domain, maybe Flight is an Aggregate and Company another one ;), don't confuse entity and Aggregate...
An aggregate is a group of entities (objects with identity) and maybe value objects (objects without identity, immutable). There is exactly one entity in an aggregate that is the aggregate root. You can easily identify it by checking if the other objects in the aggregate depend on it, for example, if you delete an object of the aggregate root type, the remaining objects don't make sense anymore (in database terms, you'd cascade delete the dependent objects).
The aggregate root is the sole object in the aggregate that gives access to the other types in the aggregate, hence you'll have one repository per aggregate and it returns instances of aggregate root type.
I am into my first week of DDD and have a couple of entities with aggregate roots defined.
I read that no external entity outside of an aggregate can reference an entity in an aggregate, so the external entity has to reference the aggregate root.
Well, unless I have modelled my solution incorrectly I need a reference to an entity behind the aggregate root. How do I handle this situation or do I have to remodel my domain to avoid this situation?
JD
You probably could refine your model. If an external reference to an entity inside your aggregate is required, then that is a strong indicator that the internal entity might be an aggregate root itself.
This of course is general advice since I don't know anything about your specific model.
For great advice concerning aggregate design, have a look at this paper by Vaughn Vernon. In Part I, "Modeling of an Aggregate", he specifically addresses aggregate granularity which I found very enlightening.
I have a few (hopefully) simple questions about aggregate roots in domain driven design:
Is it okay to have an aggregate root as a property of another aggregate root?
Is it okay to have a given entity inside two or more aggregate roots?
My final question is a bit more involved. I have a website that has a few entities that really belong to a "website" aggregate root. They are 'News', 'Products', and 'Users'. There isn't a 'Website' table in the database, but a 'Website' seems like a good aggregate root for these three entities.
How is this usually achieved?
Thanks!
Do you have any consistency rules spanning the whole website (concerning multiple news products and usesrs)? If not, these entities (news, products, users) are good candidates for being you aggregate roots.
Aggregate root main function is to provide consistency and transaction semantics boundary.
To answer you questions:
Yes, it is ok as long as this
referred aggregate root is not
modified during any operation of the
containing AR. This is connected to
the consistency boundaries:
operations spanning multiple
aggregates are not guarantied to
produce consistent results so they
should be avoided
No, an entity
(which is not AR) can be a part of
only one aggregate.