I am trying to put in practice a small DDD example but I have some dubts.

In my example, I have an Order and a Status.

The Order can be this:

    long Id;
    long IdStatus;
    long IdBuyer;
    Address Address;

    long Id;
    string Status;
    bool IsFirstState;
    bool AllowModifications;
    bool CanBeAccepted;
    //another bool properties to can check if an action can be done.

I am not sure if it is a good idea that the state it is a root entity, but I would like to can edit for example if the status property is wrong (perhaps is write wrong). So I need to can identify by ID.

Also I have properties to can know if an action can be done or not. For example, Send(), if the actual status doesn’t allow to send, then don’t do it.

I decide in this way because I can add new status in the database without needed of change the code. If I would have hardcode a fix number of states, if I need a new one, it would be harder to added new status.

Well, so really I have two questions here:

1.- The general doubt, how could access to the data of the status (or data of another root entity) from another if it is needed for the logic.

2.- If it is a good idea to stablish the status of the order as root entity.



There are many ways to model a domain. It’s quite common, in my experience, to try a few different models and see how they fit the needs. Or start somewhere and mold the model as new insights emerge.

For me it works best not to model domain classes around properties, but around behavior.

To answer your questions;

  1. an aggregate root should not depend on another aggregate root.
  2. probably not, but that depends entirely on the model. If it fulfills your needs, who are we to say its wrong?

Since this is a learning project, why not try a few different models? Try to come up with a model where aggregates don’t depend on each other and where Status is not an aggregate root.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *