DDD How to fetch a list of value objects

Question

I have a domain model

• Customer - Aggregate root - because an order can't exist without a customer
• Order - entity
• OrderStatus - value object

In my form I need a list of all OrderStatuses.

Should I fetch an empty customer entity(AR) from repository with an empty order entity which is containing a list of all OrderStatuses? This is awkward.

Worden

What do you mean by "I need a list of all OrderStatuses"? You need the list of all available values? – Overton

Answer 1

Well, it always depends on your problem domain, but lacking further info, I would say you probably need to break your modeling a little bit.

Even though an Order can't exist without a Customer, it will not be a child entity under the Customer AR. You need to introduce the notion of Bounded Contexts.

Customer would be the AR of one BC, while Order would be the AR of its own BC.

In that case, you would reference Customer from Order with a CustomerId property (not with an object reference) because they belong to different contexts, and as such they could even live in separate microservices, in separate databases.

You see where I'm going: it makes no sense to fetch an empty Customer, with an empty Order (or list of Orders) just to reach a list of Order Statuses.

Even if Order and Customer did belong to the same BC, OrderStatus is Reference Data, and would be better represented by an enum type (or better, with the Enumeration Pattern).

Have a look at this additional info:

Reference data as code

Entities, Value Objects, Aggregates and Roots

Eddins

Why you emphasized on referencing the customer by CustomerId and not an object reference ? Customer being an aggregate root, it's BC is always valid. So what's the problem in referencing It ? You don't risk to break the context consistency. I've seen some places where they do this and I fail to find a reason not to. Can you explain more ? – Jos

Referencing by id rather than an object keeps BCs decoupled, allowing them to evolve independently and scale separately. It helps to maintain consistency without the overhead of syncing both aggregates. – Eddins

If we reference objects from a different BC, changes in the foreign class directly impact the context, requiring synchronized updates. Object references may force both contexts to reside in the same service or database, limiting scalability. Using CustomerId allows each context to manage its own data and logic, enabling independent deployment cycles and reducing downtime. – Eddins

It's not forbidden to reference by object in DDD (as it doesn't enforce any particular tech choices), but referencing by CustomerId helps prevent tight coupling, reduces complexity, enhances scalability, and allows bounded contexts to evolve and scale independently. This aligns with DDD principles by maintaining clear boundaries and promoting a more flexible and maintainable architecture. – Eddins

"changes in the foreign class directly impact the context, requiring synchronized updates." That should not be the case if we reference an AR. If a AR requires synchronization with another AR changes then they are not really bounded contexts I think. They should be separate and valid at all times. enterprisecraftsmanship.com/posts/… Event this article from "Vladimir Khorikov" says It should be an object reference rather than Id reference. I'm trying to know why say always reference by id. I think both methods are valid – Jos

Also if you use id reference, this requires using the IRepository inside the domain layer to get the entity right ? Shouldn't we add to this "Only reference an AR" ? because even with id reference if you reference and entity you might get it from a BC that will eventually become consistent. right or am i missing something basic here ? – Jos