relationship between upstream context and downstream context in ddd

user_14645364 0
Viewed 1217

Recently, I learn about ddd and it said that the relationship between two related bounded context is upstream and downstream.

But is it possible that in one situation A is upstream and B is downstream and in another situation B is upstream and downstream?

But if it is possible, I think the two bounded context is highly coupling. They are not independent business logic. So when that happens, does is mean that we do not divide domain correctly into bounded context?

Or we do allow communication between the two bounded context to some degree and if there are so many APIs they call from each other, they are actually one bounded context but we do not correctly divide it.

bounded-contexts domain-driven-design
1 Answers

An upstream context will influence the downstream counterpart while the opposite might not be true. For instance, imagine there are two micro-services as bounded contexts, MoneyTransferService along with NotificationService. If money is transferred, notification should send an email, which includes some info related the transaction, to the customer. So MoneyTransferService is upstream NotificationService is downstream

DDD describes several organizational patterns that help us describe and/or manage the way different contexts interact. The most suitable pattern here is called Anti-Corruption Layer (ACL). In order to follow this pattern in my example, to communicate with two micro-services, Repository layer could be used or a better solution is publish messages and consume them by tools like RabbitMQ. By using RabbitMQ, these services is just dependent on the message type, no need to know anything else.

As far as dependency is concerned, interaction between bounded contexts doesn't mean having dependency between them and you don't necessarily need to redesign them as a bounded context.

Your goal should be to get to the most meaningful separation guided by your domain knowledge. The emphasis isn't on the size, but instead on business capabilities. In addition, if there's clear cohesion needed for a certain area of the application based on a high number of dependencies, that indicates the need for a single bounded context, too. There is nothing wrong with communications between bounded contexts which need each other to complete their business operations.

user_61344080
Related