EntityA is an aggregate root and is having many EntityB entities. EntityB is having many EntityC entities. EntityC is referencing back both EntityB (original parent) and EntityA (null when EntityC is created).
At one point I want to set EntityA as a "new parent" of EntityC, so in EntityC I would set the reference to original EntityB parent to null, and would set the reference to EntityA (was null previously).
Is this "dynamic entity parent" idea compatible with DDD?
One of the central considerations when designing an aggregate is to regard it as a consistency boundary. So when you're thinking about whether various relationships between constituent entities should be expressed, consider whether these relationships are required to implement behaviors and whether they are required to remain consistent after execution of said behavior. DDD doesn't dictate the implementation of the object model itself so much as it dictates the focus on behavior and transactional consistency. Also many times, relationships are implemented to support a query scenario. In these cases, instead of polluting the aggregate, create a separate read-model. Also, take a look at effective aggregate design.
Your idea is definitely compatible with DDD. However, how you go about implementing it is important.
As eulerfx has pointed out the aggregate design is relevant here. I do suspect, though, that you may have some form of classification structure. This means that the representation of that structure may become a new set of entities / aggregates. Or, if not a full blown sub-domain, then maybe have the classification represented by value objects in the entities. But references to other aggregates within an aggregate is a bit of a red flag should you find yourself in that position.
Related
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 just started on DDD and encounter the term aggregate roots.
My current understanding is that this is kind of a parent entity that hold reference to other complementary entity. Example : aggregate roots will be Employee that also contain position, shift, gender, and salary.
My first question will be whether this understanding is correct ?
Secondly, I get an impression that repository is defined only for each aggregate. Yet, it puzzles me how we could retrieve information regarding other entity (Ex: list of positions or shift type) ?
Thank you,
Aggregates are consistency boundaries to enforce invariants. This means that the entities and objects inside the aggregate must remain consistent together with regards to the business rules.
http://dddcommunity.org/library/vernon_2011/
http://martinfowler.com/bliki/DDD_Aggregate.html
https://lostechies.com/gabrielschenker/2015/05/25/ddd-the-aggregate/
Secondly, I get an impression that repository is defined only for each aggregate. Yet, it is puzzle me how we could retrieve information regarding other entity (Ex : list of positions or shift type) ?
You can have a separate read model over your data if you choose to do so and it makes sense that the business wants to view the data in a different way. The consistencies you need to enforce when you are writing data do not apply on the read side. CQRS is the pattern to help with this - you separate your write side from your read side.
https://lostechies.com/gabrielschenker/2015/04/07/cqrs-revisited
From a post I read it seems that Entity is just a subset of Aggregate. I've read about the two patterns in both Domain-Driven Design and Implementing Domain-Driven Design, and I'm trying to understand the UML difference between them.
Let's consider a simple class. It's a Letter holding a message, a receiver, and possibly the sender.
I guess this Letter class would be considered an Entity?
Now let's say we want to expand our parcel business to be able to send also Packages, then it could look like the following.
Since all the Items in the Package will be lost if the whole Package is lost, we use a UML Composition relation (a filled diamond). We also want to preserve the Package's consistency by prohibiting Items from being changed or removed from outside the Package. The description of Aggregate reads
The aggregate root guarantees the consistency of changes being made
within the aggregate by forbidding external objects from holding
references to its members.
We therefore make sure the Composition relation is hidden, and with preserved invariants, within the Aggregate.
My question is:
Can we say that the UML difference between Entity and Aggregate is that Entity does not contain any Composition relation whereas Aggregate contains at least one Composition relation?
To answer your question, no you can't say that. An aggregate root is entity itself, and may or may not be composed of child entities. The child entities can also be composed of other entities as well (though not recommended usually).
The aggregate root is responsible for maintaining the state and enforcing the invariants of both itself and it's child entities.
So to recap, an aggregate and a child entity can each have 0 or more child entities. All child entities require an aggregate root however.
An Entity represents the M(odel) in MVC. It's usually denoted as a <<entity>> stereotyped class.
An Aggregate is a synonym for a class which aggregates different other classes. That means it needs the other classes for its life time. There's also a Composite which is similar except that the related class instances will die along with the composite class.
To answer your final question: an Entity is atomar. It does not aggregate anything.
Edit Since I just encountered it for my work: There are Entities which compose/aggregate other entities. 30 years ago at university we called them trapeze for they hang between two other entities and relate them. Nowadays I'd call them association class.
An Entity in Domain-Driven-Design (DDD) is just a class stereotype in UML terms. That stereotype indicates to you that the object is identified by an explicit unique identifier, rather than its attributes.
Objects in an object model collaborate together. Together they form object graphs. An Aggregate represents a group of objects that need to be considered together because not doing so would potentially leave one or more of the objects in an invalid state.
"Can we say that the UML difference between Entity and Aggregate is that Entity does not contain any Composition relation whereas Aggregate contains at least one Composition relation?"
No. A UML composition or aggregation association is unrelated to the concept of DDD Aggregate or Entity.
For example, one can represent a Transaction-LineItem relationship in UML without composition or (UML) aggregation.
Transaction --- 1 -------- 0..* --- LineItem
Both these objects as modeled above would need to be part of the same (DDD) Aggregate because they need to be treated as a pair. If mistreated individually, one could make their combined states invalid or incorrect.
After reading Evans and Vernon I still have one fundamental Question.
I'm aware that of course one entity (instance) can only be in one aggregate.
But can an entity class be used in multiple aggregates (classes)?
For clarification, I ask on the class level.
Other formulation: Can two different aggregate root classes (!) aggregate the same entity class? Of course any of the entity instances has to belong to only one instance of one of the two aggregate root classes.
For Value Object classes this seems to be possible. At least I have the impression that a value object class for example for "money" can be used in different aggregate types.
As you rightly pointed out, Entity instances shouldn't be shared between aggregates, as one aggregate wouldn't be aware of changes to the entity made through another aggregate and couldn't enforce its invariants.
Entity classes could theoretically be shared between 2 aggregates, but, by the same reasoning, only if the set of entity instances in an Aggregate is disjoint from the other. This raises questions :
Why would you want that in the first place ? If there are two big categories of instances of the same class, isn't this a sign that there are two semantically different concepts, which should each have their own class, or at least subclass ?
How do you prevent an entity instance belonging to one aggregate from being added to the other, at runtime (bug), or at programming time (uneducated developer decision) ?
Value Objects escape these issues because they are usually immutable or treated as such -- you don't modify a VO, you modify its parent Entity so that it points to a whole new VO instance. Also, as Value Objects don't have an identity, it doesn't make much sense to say that the "same" VO is in two aggregates at the same time. You can thus safely reuse a VO type in different aggregate classes.
I think Udi's blog post here is very relevant - he suggests that entities can not only be part of multiple aggregates but also be an aggregate root themselves. It is a bit of a funny one to get your head around! http://udidahan.com/2009/06/29/dont-create-aggregate-roots/
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.