I'm working on an ordering system where we receive tab delimited files that look like this (I removed most of the columns for clarity):

      OrderId   OrderLineId    BuyerName   BuyerAdress   RecipientName     RecipientAdress

         1            1         John        123, Street      Doe              25, street
         1            2         John        123, Street      Doe              25, street
         1            3         John        123, Street     Michael           11, France
         2            1         Sam         66,Somewhere     Lily             25, Poland
         2            2         Sam         66,Somewhere     Dave             25, Russia

Applying DDD I primarily extracted few entities as shown in the image below:

enter image description here

Some facts about the data received in the files:

  1. An Order must have a Buyer and a Buyer must have an Order .
  2. An Order contains at least 1 OrderLine and each OrderLine must belong to an Order.
  3. Each OrderLine must have a Recipient and each Recipient must have an associated OrderLine.
  4. The status history for the OrderLine must be tracked by the system (hence the Line History entity)


  1. Which entity is the aggregate root? Most of the articles I read about DDD would put the Customer entity as its own aggregate root and the Order with its OrderLines as the other root. However, since the Buyer and Recipient can NOT exist by themselves how can they be treated as their own aggregate root?
  2. Should OrderLines be a value object or an entity? I have seen some answers on numerous blogs suggesting the OrderLines should be a VO, but I don't see why it shouldn't be treated as an entity since its identity will be needed in its relation with the History entity.
  3. Similarly the Line History should be modeled as entity or value object

2 Answers 2


I think you missed one thing in DDD. And that is relationship between entities is expensive and you should think twice before adding it. You only add entity relationship if it is completely necessary. In your case, Buyer has no need to have lists of his orders. And there is no need for Recipient having list of order Lines. There is no need for those to exist inside the entities, but they should instead be modeled inside the repository. So you can get orders of given buyer and order lines of given recipient.

Also, there can be as many aggregate roots as there are entities in the design. Nowhere it says to have single aggregate root in whole design.

If I go by my logic, then there are 3 aggregates and roots in your design : Buyer, Recipient and Order with Order lines and Line history.

2 and 3 : Yeah it is logical that Order lines would be entity thanks to the relationship to their history. But I think they should still be part of order aggregate.


It looks like your buyer and recipient are value objects as they have no identity outside the relationship to an order and order line. I would therefore say that Order is an aggregate root and also order history is an aggregate root that is updated from events that happen within the order aggregate. I cover this in my free DDD book https://leanpub.com/Practicing-DDD

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.