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
  • P.S.: I've abstracted as much as possible the technologies involved on the implementation of this system because the question goal is to get a conceptual answer.
    – user290239
    Sep 25, 2019 at 12:17

2 Answers 2


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

  • Nachiappan, thank you for your answer! The intent is really to prevent the domain from being modeled just to resolve technological matters, so we will take a look and research on the event store suggestion. In time, the provided alternative of storing the relation as a serialized json-ish column is also good for our scenario, we actually do that in another aggregate, since our dbms have great support for it.
    – user290239
    Sep 25, 2019 at 14:19

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

  • Ewan, the entire graph loading is actually a desired behaviour for this system, it will be lazily loaded as required, so if it doesn't hurt the aggregation, we are fine with it, thank you for the explanation!
    – user290239
    Sep 25, 2019 at 14:13
  • In time, just for clarifying, in the example, the Car is indeed the only aggregation root and Computer only exists within the Car :)
    – user290239
    Sep 25, 2019 at 14:13
  • Fixed the question, you are correct, it should be "Car is the aggregation root" and "Car and Computer are in the same aggregate" ;)
    – user290239
    Sep 25, 2019 at 14:15
  • @danieldeveloper001 Computer is the AR
    – Ewan
    Sep 25, 2019 at 15:36
  • Ewan, sorry, could you please elaborate? The main entity for this aggregate is Car and the entity which is supposed to depend upon other to exist is Computer. Why would Computer be the aggregation root? Many thanks!
    – user290239
    Sep 25, 2019 at 15:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.