Domain Driven Design - update of value objects

Question

I'm quite new to DDD and I'm still reading about it. While reading I had some doubt about aggregates sharing some data with other aggregates. As an example, assume that I'm developing an online store, I would model an Account aggregate and an Order aggregate. Now, assume that some of the data of the Account aggregate is really needed by the Order aggregate to accomplish all business cases. Following DDD strictly, I should model the Order aggregate to have a value object holing the identity of the Account aggregate and ask for the needed Account data all the time. Should I still model it as a value object holding the identity and always ask for the needed data or can I create the value object so that it holds the needed data all the time?

This way the data is always around, however, this data also need to be in sync with the real Account aggregate data.

Thank you

Answer 1

A very common approach to dealing with downstream systems is using some messaging mechanism. An event-driven architecture gets this done really nicely.

What you sometimes have to ask yourself is whether the data really has to be updated at all. Perhaps for an active order you may want to update the customer name when the upstream BC publishes the relevant event containing the new name. Orders that have been completed may very well be left alone. This would typically be the case when someone's surname changes.

Another example where you may not want to change the data is the product description. If the client ordered a "box of red pens" with SKU BP-001 and the back-end updates an error and changes the description to "box of blue pens" then that may lead to an interesting argument.

Any downstream system that requires updates will have data that may very well be stale. In most cases it shouldn't be a problem as they will eventually be consistent.

Sometimes you deal the deck and sometimes you play the hand that you have been dealt.

Answer 2

You could represent the Customer in the Order as an immutable value object, holding all the attributes you need as primitive data types. Or you will reference to this Account Aggregate with an identity value object in the Order Aggregate. This will assume, that the two aggregates are living in the same Bounded Context, but i doubt that's the case. Because obviously you're describing the same thing with different meanings in the aggregates (Account and Customer) so the Ubiquitous Language is different. In one Aggregate it is an Account and in Order it is a Customer. So that's a first sign, that it should be located in two different Bounded Contexts. You could have an Identity Access Context where you speak about Accounts and you could have an Order Context where you speak about Customers. In your Order Context then, you can fetch the Customer information from the Accounting Context through an Anticorruption Layer, which will translate an Account to a Customer Value Object.

Answer 3

Should I still model it as a value object holding the identity and always ask for the needed data or can I create the value object so that it holds the needed data all the time?

"It depends".

(If you are learning DDD, get used to that answer - it comes up frequently.)

One of the key ideas of aggregates is that you are partitioning your information; any given piece of information in your domain model is "owned" by at most one aggregate, which is to say only one aggregate is permitted to acquire the lock on that data and modify it.

Everybody else working with that data is looking at an unlocked copy. The important thing to remember about unlocked copies is that they may be out of date (the Account aggregate can change the information without asking for permission from the Order aggregate).

So what you are really asking is something like "should the Order aggregate always ask for a fresh copy of the account information when it needs it? Or should we instead cache a copy of that information inside the Order aggregate?

The answer is going to depend on a number of things like "is the account information always available?" "how much tolerance does your Order business logic have for outdated Account information?" and so on.

(Hint: if your Order business logic has no tolerance at all for outdated Account information, that strongly suggests that you have designed your aggregate boundaries incorrectly)