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.
Related
I'm looking into the possibility of adopting the concept of (root) aggregates from domain-driven design in a system without an event store. However, the more I discover about the two, the more it feels like the one cannot exist without the other.
I haven't finished reading the blue book yet, but my understanding of a root aggregate so far is that it's a "tree" of aggregates that needs to be consistent within that root aggregate. An aggregate can only be modified through the root aggregate it belongs to. Finally, a root can basically be defined by "does it make sense to have this aggregate independent and can it exist by itself in this domain?".
Imagine a green-field project where it doesn't make sense to engineer event sourcing yet, but might benefit from it in the future. The absence of an event store would eliminate the possibility to keep track of all the domain events shaping a root aggregate at a specific point in time. The commands would have to mutate the root aggregate. In addition, the read side would be limited to react on "root aggregate {id} has updated" as there's no event replayability.
Is there any reasonable way for the concept of (root) aggregates to exist without an event store, or should one stick to the "traditional" entity modeling until it makes sense to invest in event sourcing?
I believe you are confusing things. There's no such thing as root aggregate or a tree of aggregates.
The main purpose of the aggregate tactical pattern in DDD to exist is to define the consistency boundary, which technically translates to the transactional boundary. Everything inside one aggregate can change when you handle a single command, but no more.
An aggregate can consist of several entity types. However, only one entity type serves as the aggregate root. The aggregate root id is the identity for the whole aggregate. Other entities inside the aggregate will have their ids (otherwise these aren't entities but value objects) but those entities cannot be amended or referred directly from outside of the aggregate and all operations on all entities inside one aggregate go vis the aggregate root.
The most typical example of an aggregate is the Order, where Order itself (or OrderHead if you like) is the root and OrderLine is the entity. You can have multiple order lines for one order but all operations on any line go via the root.
There's no direct and explicit connection between the aggregate pattern and event-sourcing. Event-sourcing is the implementation details. Eric Evans book doesn't even mention event-sourcing as such and it has quite a few examples of aggregates.
Event-sourcing is the way to persist data. In fact, event-sourcing is completely unrelated to DDD, although Greg Young originally proposed using event-sourcing as the way to persist aggregates by storing domain events.
When you have a pure domain model, it doesn't really matter from the domain model side what persistence mechanism you use. Many event-sourced systems have no concept of aggregate at all. For example, The New York Times has built an event-sourced content management system without any DDD tactical pattern in mind. From the other side, the majority of systems that use tactical DDD patterns do not use event-sourcing and use just state-based persistence.
If we are working on a sub-domain where we're only dealing with a read-only scenario, meaning that our entities and value objects will not be changed, does it make sense to create aggregates composed by roots and its children or should each entity of this context map to a single aggregate?
Imagine that we've entity A and entity B.
In a context where modifications are made, we create an aggregate composed by entity A and entity B, where A is the aggregate root (let's say that B can't live without A and there are some invariants involved).
If we move the same entities to a different context where no modifications are made, does it make sense to keep this aggregate or should we create an aggregate for entity A and a different one for entity B?
In 2019, there's fairly large support for the idea that in a read only scenario, you don't bother with the domain model at all.
Just load the data directly into whatever read only data structure makes sense to support the use case.
See also: cqrs.
The first thing is if B cant live without A and there are some invariants involved, to me A is an Aggregate root, with B being an entity that belongs to it.
Aggregate roots represent a real world concept and dont just exist for the convenience of modification. In many of our applications, we don't modify state of our aggregate roots once created - i.e. we in effect have immutable aggregate roots. These would have some logic for design by contract checks/invariant checks etc but they are in effect anaemic as there is no "Update" methods due to its immutability. Since the "blue book" was written by Eric Evans, alot of things have changed, e.g. the concept of NoSql database have become very popular, functional programming concepts have become very influential rising to more advanced DDD style architectures being recommended such as CQRS. So for example, rather than doing updates to a database I can append (i.e. insert) instead. This leads to aggregates no longer having to be "updated". This leads to leaner anaemic types but this is what we want in this context. The issue before with anaemic types was that "update logic" for a given type was put elsewhere in the codebase instead of being put into the type itself. However if you do not require "update logic" in the first place then you dont have that problem!
If for example there is an Order with many OrderItems, we would create an Order aggregate root and an OrderItem entity. Its a very important concept to distill your domain to properly identify what are aggregates, entities and value types.
Then creation of domain services, repositories etc just flows naturally. For example, aggregate roots and repositories are 1 to 1 i.e. in the example above we would have an Order repository and not have an OrderItem repository. That way your main domain concepts are spread throughout your code in a predictable and easy to understand way.
Finally, in your specific question I would not treat them as the same entities. In one context, you seem to need modification logic - in the other they you dont - they are separate domain concepts to me.
In context where modifications are made: A=agg root, B=entity.
In context without modifications: A=agg root (immutable), B=entity(immutable)
I have a question regarding the design of aggregates, as presented by Vernon, both in his articles in the DDD community (Effective Aggregate Design, Part 3) as well as on his book (Implementing Domain-Driven Design).
In there, he explores two possible approaches when designing BacklogItem and Task. In one of them Task is not its own Aggregate Root because it runs the "risk of leaving the true invariant unprotected", and the aggregate root is the BacklogItem
However, one of the other guidelines for designing aggregates roots is that access to an entity should only be done through the root itself. Which means that in order to get access to a Task in this approach one would have to now the BacklogItem it belongs to and ask for the backlog item. Normally, though one would just want to see the Tasks is assigned with, and not the backlog item.
In this case we will need to access the entity directly and not via the Backlog item. How does this sit with the proposed design? (I understand that this may be just an educational demo but how would someone have to think this if this was real life?)
Thanks in advance for any answers
In this case we will need to access the entity directly and not via the Backlog item. How does this sit with the proposed design?
That depends: "access directly" is under specified.
Bertrand Mayer's language of command query separation helps here. Queries leave the model unchanged; commands update the model.
Here's the key idea: the unique concern of the aggregate root is commands; any change to the state of the aggregate is achieved by sending a command to the root entity, which may at its discretion delegate the responsibility of changing the state to some other entity.
So if you are accessing the Task to query its current state, that's just fine. But getting the Task so that you can send commands to it directly? that breaks the rules. The aggregate root has the privilege of exclusive access to the commands of all of the entities within the aggregate.
The implication is that you would never invoke Task.estimateRemainingHours() directly; you would instead invoke some analogous method on the aggregate root. BacklogItem.logEstimateFromTeamMember(), perhaps, which would in turn decide which tasks need to be updated.
I'm struggling with some implementation details when looking at the terms mentioned in the title above.
Can someone tell me whether my interpretation is right?
For reference I look at a CRM Domain
As a AggregateRoot I could see a Customer.
It may have Entities like Address which contains street, postal code and so on.
Now there is something like Contact and Activity this should be at least aggregates. Right? Now if the Contacts and Activities would have complex business logic. For example, "Every time a contact of the type order is created, the order workflow should be started"
Would then Contact need to be an Aggregate root? What may be implementation implications that could result from this?
Further more when looking and Event Sourcing, Would each Aggregate have its own Stream? In this scenario A Customer could have thousands of activities.
It would be great if someone could guide em in which part my understanding is right and which I differ form the common interpretation.
What do you mean by “at least aggregates”?
An aggregate is a set of one or more connected entities. The aggregate can only be accessed from its root entity, also called the aggregate root. The aggregate defines the transactional boundaries for the entities which must be preserved at all time. Jimmy Bogard has a good explanation of aggregates here.
When using event sourcing each aggregate should have its own stream. The stream is used to construct the aggregates and there is no reason to let several aggregates use the same stream.
You should try to keep your aggregates small. If you expect your customer object to have thousands of activities then you should look at if it is possible to design the activities as a separate aggregate, just as long as its boundaries ensures that you do not leave the system in an invalid state.
Ive heard a lots that aggregate roots depend on the use case. But what does that mean in coding context ?
You have a service class which offcourse hold methods (use cases) that gonna accomplish something in a repository. Great, so you use a repository which is equal to an aggregate root to perform your querying.
Now you need to perform some other kind of operation which use totally different use case than the first service class but use the same entities.
Here the representation :
Entities: Customer, Orders, LineOrder
Service 1: Add new customers, Delete some customers, retrieve customer orders
Here the aggregate root seem to be Customer because you need this repository to perform thoses use cases.
Service 2: Retrieve customer from an actual order
Here the aggregate root seem to be Order because you need this repository to perform this use case.
If i am wrong please correct me. Now that mean you have 2 aggregates roots.
Now my question is, since aggregate roots depend on the use case does that mean that we might end up with really a lots of repositories if you end up having lots of use cases ?
The above example was probably not the best example... so lets say we have a Journal which hold JournalEntries which each entries hold Tasks, Problems and Notes. (This is in the context of telling to a system what have been done to a project)
Does that mean that im gonna end up with 2 repository ? (Journal, JournalEntry)
In the use cases where i need to add new tasks, problems and notes from an journal entry ?
(Can be seen as a service)
Or might end up with 4 repository. (Journal, Task, Problems, Notes)
In the use cases where i need to access directment task, problems and notes ?
(Can be seen as another service)
But that would mean if i need both of theses services (that actually hold the use cases) that i actually need 5 repository to be able to perform use cases in both of them ?
Thanks.
Hi I saw your post and thought I may give you my opion. First I must say I've been doing DDD in project for three years now, so I'm not an expert. But I'm currently working in a project as an architect an coaching developers in DDD, and I must say it isn't a walk in the park... I don't know how many times I've refactored the model and Entity relationships.
But my experience is that you endup with some repositories (more than few but not many). My Aggregates usually contains a few classes and the Aggregate object graph isn't that deep (if you know what I mean).
But I try to be concrete:
1) Aggregate roots are defined by your needs. I mean if you feel that you need that Tasks object through Journal to often, then maybe thats a sign for it to be upgraded as a aggregate root.
2) But everything cannot be aggregate roots, so try to capsulate object that are tight related. Notes seems like a candidate for being own by a root object. You'd probably always relate Notes to the root or it loses its context. Notes cannot live by itself.
3) Remember that Aggregates are used for splitting up large complex domains into smaller "islands" that take care of thier inhabbitants. Its important to not make your domain more complex than it is.
4) You don't know how your model look likes before you've reached far into the project implementation phase. If you realize that some repositories aren't used that much, they may be candidates for merging into other root object (if they have that kind of relationship). You can break out objects that are used so much through root object without its context. I mean for example if Journal are aggregate root and contains Notes and Tasks. After a while you model grows and maybe Tasks
have assoications to Action and ActionHistory and User and Rule and Permission. Now I just throw out a bunch om common objects in a rule/action/user permission functionality. Maybe this result in usecases that approach Tasks from another angle, "View all Tasks performed by this User" etc. Tasks get more involved in some kind of State/Workflow engine and therefor candidates for being an aggregate root itself.
Okey. Not the best example but it maybe gives you the idea. A root object can contain children where some of its children can also be root object because we need it in another context (than journal).
But I have myself banged my head against the wall everytime you startup with a fresh model. Just go with the flow and let the model evolve itself through its clients/subsribers. You refine the model through its usage. The Services (application services and not domain services) are of course extended with methods that respond to UI and usecases (often one-to-one).
I hope I helped you in someway...or not :D
Yes, you would most likely end up with 5 repositories (Journal, JournalEntry, Task, Problems, Notes). Your services would then use these repositories to perform CRUD for each type of entity.
Your reaction of "wow so many repositories" is not uncommon for developers new to DDD.
However, your repositories are usually light weight assuming your model and DB schema are fairly evenly matched which is often the case. If you use an ORM such as nHibernate or a tool such as codesmith generator then it gets even easier to create your repositories.
At first you need to define what is aggregate. I don't know about use case aggregates.
I know about aggregates following...
Aggregates are union of several entities. One of the entities is the aggregate root, the rest entities (or value types) have sense only in selected aggregate root context. For example you can define Order and OrderLine as an aggregate if you don't need to do any independent actions with OrderLine entities. It means that OrderLine makes sense in Order context only.
Why to define aggregates at all? It is required to reduce references between objects. That will simplify you domain model.
And of course you don't need to have OrderLineRepository if OrderLine is a part of Order aggregate.
Here is a link with more information. You can read Eric Evans DDD book. He explains aggregates very well.