Consider an application being implemented following Domain Driven Design.
In the same aggregation, there are Car and Computer entities that should have a one to many relationship between them (Car has one Computer and Computer can be embedded in many of Car). They are in the same aggregation because Computer only exists within Car, so the Car is the aggregation root. Below, some simplified pseudo code.
The application uses for persistence an orm that requires such entities to have explicit relationship configuration between them using references and back references such as Computer computer and Car[] cars.
Does the usage of these references between the classes on the same aggregation root hurt the aggregate pattern principle from domain driven design? In time, the only reason why Computer have an identifier, is because these entities will be persisted in different tables on the database.
class Car
uuid id
string name
string color
# Here is the reference
uuid computer_id
Computer computer
class Computer
uuid id
string processor
int memory
int storage
# Here is the back reference
Car[] cars
1
To your question: “Does the usage of these references between the classes on the same aggregation root hurt the aggregate pattern principle from domain driven design?”. No. This is the intention of aggregate. One of the entity should be able to refer other entity in the same aggregate.
When you are doing DDD, aggregates are transactional boundary. And when you are persisting the entities in a normalized form in a database it could be hard to make aggregates as transactional boundary. To make aggregates as your transactional boundary, you would have to implement a lot of event store logic. Instead, I would prefer to use a [event store] (https://eventstore.org/), or (if using c#) use a library such as SqlStreamStore or NEventStore.
Or when none of these are feasible to me I would store the aggregate in serialized form along with aggregate version and aggregate id. With this it would relatively easy for me to build transactional boundary around an aggregate.
To answer in short, I would not choose to use a ORM and persist aggregates in normalized form because enforcing transactional boundary is difficult. For me this is the only issue and nothing else
1
In the same aggregation root, there are Car and Computer
I think this is where you are going wrong.
In your example Computer is the Aggregate Root. You can only have one ‘root’ object per aggregate.
If you think of things this way around your object graph just becomes a standard parent-child tree where you need to load all the objects in order to keep calculated properties on the parent valid.
Having a child reference its parent like you have is fine as long as you are happy to load the entire graph when you need a single car.
Otherwise it would be better to simply have the the computerId property as a cross aggregate link
6