I see a lot of guidance in the DDD community around how to retrieve and use information from a remote bounded context (using an anticorruption layer, open host service, etc.), but hardly anything about how to handle storage of attributes that matter in the local bounded context for an entity that has its home in a remote bounded context.

For example, our Scheduling BC has a Client, and we only need some of its attributes in our Accounting BC. Easy enough, just grab it through an anticorruption layer which creates a trimmed-down Client for us.

But we also need to handle updating the billing address for Client, and my understanding is that a downstream BC representation of an upstream BC entity should be read-only. But it's the Accounting BC that cares about the billing address, and we wouldn't even be asking for a billing address without the Accounting BC in place.

So doesn't it make sense that the Accounting BC would be the one to handle storing this information? If so, how?

This is just one example, but it seems like a common pattern, doesn't it? I'm sure it's been discussed somewhere, I just can't find it.

Update: This question gets at the very issue I’m concerned with, though there aren’t currently any satisfactory answers.

  • my understanding is that a downstream BC representation of an upstream BC concept should be read-only -- Can you provide an online citation for this assertion? If you need read-write attributes on a BC, and downstream representations of a BC are read-only, then logically it would seem that you need a BC to handle Clients. – Robert Harvey Oct 16 '18 at 21:17
  • @RobertHarvey I suppose that's really what I'm asking about here: is my understanding correct? I can't find any authoritative source for it, it's just my understanding because it seems as though every example I've found of interaction between bounded contexts shows a read-only translation. But that may be for the sake of keeping the example simple. – Kevin Smith Oct 16 '18 at 21:35
  • You may update the information downstream whenever it changes, if you need this. There is no rule stating otherwise. – Constantin Galbenu Oct 17 '18 at 8:50
  • This answer (stackoverflow.com/a/50693956) is the usual sort of guidance on read-only in the downstream context that I was talking about, @RobertHarvey. And ironically, it turns out it was written by @ConstantinGalbenu! Hopefully you can help me understand what I’m missing here, Constantin. – Kevin Smith Oct 17 '18 at 11:33
  • Wouldn't a Billing Address be a separate entity? In that case, this would not be downstream BC representation and it doesn't need to be read-only. – Jonathan van de Veen Nov 14 '18 at 10:05

I sent this question to Vaughn Vernon, and he was very helpful in response. Posted his answers below for posterity.

In Summary: After his clarifying insight, I realized the Scheduling BC is the system of record for Client, and the Accounting BC manages the life cycle of a separate Client entity concerned with billing information. If any Client information from Scheduling is needed in Accounting, that can be synced over out-of-band.

From what I know, which from your question isn't much, it's two different objects. When modifying the local object you need a way to reflect dependent modifications on the remote object. Domain events can communicate the need for compensating modifications, but hopefully !1:1.

- @VaughnVernon

I then asked: Should one BC have authority over life-cycle (especially concerning persistence), or should they each manage that in their own way? (It does seem like they are indeed 2 separate objects, each representing different aspects of a Client.)

Separate. Compensating updates are eventual. If the business requires single transactional consistency for both then it's the same context and aggregate and separation of strongly consistent attributes is wrong. [emphasis added]

- @VaughnVernon

The bolded text is what made it click for me. Thinking about it in terms of transactional consistency reveals whether I've drawn the bounded context (or even the aggregate boundaries) in the right place.

I then asked: Given a BC is only concerned with concepts (and therefore elements, attributes, etc.) that matter within that BC, it would thus seem inappropriate to have a master Client in a single BC that stores all attr, even attr that BC doesn't care about. Do I have that right?

There is certainly a system of record for one of the two that exists first, and may ultimately impact the lifecycle of the second, but it doesn't "control" the updates to the second because they are separate languages.

- @VaughnVernon

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.