Fetching data from other bounded context

[pedroabi]

As I have seen, on the service layer, we are injecting the uow that is responsible for data storage and retrieval of the aggregate root. My question is: In some situation, I will need to fetch data from other bounded context (they could be an internal rest API, if we are talking about microservices) or using another uow (if we are talking about a monolith architecture).

I suppose that the correct way of do that is inject those dependencies as in chapter 12. Am I right?

Best

[hjwp]

related to #156

[hjwp]

good question. I'm a bit scared of answering I'm afraid, @bobthemighty is the expert.

Let me have a go though, and be aware that you are talking to an expert beginner.

i think one way of answering it is to say "if your bounded context needs data from outside, then it's not a bounded context". which is not very helpful i know.

what it's driving at is that each bounded context is meant to be self-sufficient. When one needs data from another, we try to figure out exactly what data, and we incorporate that into the bounded context's own model. and then we figure out how to build ways of getting that data, whilst still keeping the two contexts as decoupled as possible. in the DDD world, there's a thing called "anticorruption layer" which is sometimes used.

in a microservices world, maybe we have a products tool that the buying team use to store information about products - sku, description, size, unit price, supplier, etc etc. In another service, we don't care about all that information, only a subset. the warehouse doesn't care about price, for example. So the products tool emits some events called ProductCreated and ProductUPdated which the warehouse service subscribes to, and builds its own subset copy of the products database, which is eventually consistent.

In a monolith world i don't have any personal/direct experience of what good patterns might be, @bobthemighty can say more perhaps.

it's possible that you're asking a different question though. Maybe we are in the same bounded context, but it's just one aggregate that wants to know something about another. That's a more common problem, cf #156, and here the solutions are things like:

• making sure the required data is read-only
• preferring the service-layer to know about multiple aggregates, rather than one aggregate knowing about another
• seeing if we can pass the responsibility from one aggregate to another using a domain event and a different handler

[hjwp]

by some sort of synchronicity, this FAQ was in my browser tabs - http://cqrs.nu/Faq , see the section How can I communicate between bounded contexts?

[hjwp]

Chapter 14 in the blue book also has some good stuff on this. some summary guidelines:

• communicating between bounded contexts means there are two different, incompatible models. you need some sort of translation layer
• you can have collaboration between different aggregates within the same model, but you need to be a bit careful about who is responsible for what data. it's probably safer to implement that collaboration in the service layer, rather than having the aggregates know too much about each other.

[hjwp]

I'm closing this in favour of #156