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:
Some facts about the data received in the files:
- An Order must have a Buyer and a Buyer must have an Order .
- An Order contains at least 1 OrderLine and each OrderLine must belong to an Order.
- Each OrderLine must have a Recipient and each Recipient must have an associated OrderLine.
- The status history for the OrderLine must be tracked by the system (hence the Line History entity)
- 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?
- 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.
- Similarly the Line History should be modeled as entity or value object