How to design, Order and State in DDD?

Álvaro García 0
Viewed 47

Supose I have an order and it can be in an state.

Order it would be the root entity, and State another root entity in the same bundary context than the order.

I was thinking that State it should be an entity too because it would be in this way:

State
{
   long Id,
   string State;
   bool AllowModifyOrder;
   bool AllowAceptorder;
   //another properties that define what is possible to do in the state.
}

So I think it is needed that the State it is another entity, not a value object. But I am not sure if this it would be the best option.

Another doubt that I have is that the order need a property to point to the state, but not to the class, but to the ID, because I have read that an entity it is better to use the ID instead of the object, to avoid try to access or modify a root entity from another. But in this case, when I need some data of the state, for example if it can be accepted or if it can be modify. How could I do that if I only have the ID of the state?

Thanks.

domain-driven-design
1 Answers

Your State has to be a property of an Order because your Ubiquitous Language says "An Order can be in a state". You are tieing yourself too closely to the Database Model. That's why you have Id's and properties that look like Columns in your class.

If an Order has a State and there's a finite amount of States, then your State can be modeled as an Enum. Take this C# code for an example:

public Enum OrderState {
  Draft,
  Open,
  Closed
}

public class Order {
  OrderState State { get; private set; }
}

Your Repositories and Factories will take care of translating what you have in your Database and Inputs into Domain Classes like Order.

usersGta0
Related