Appropriately coupled bounded contexts
If all coupling could be avoided, software architecture would be a lot easier. In real-world applications, a bounded context very likely needs the help of another bounded context to do its work.
An example is again our bounded context that is concerned with money transactions. For security reasons, we’ll want to log which user has issued a transaction. That means that our bounded context needs some information about the user, which lives in another bounded context. But our bounded context doesn’t need to be tightly coupled to the user management context.
Instead of having to know the whole user object in our “transaction management” bounded context, it might be enough to just know the user’s ID. While a user object in the “registration” context is a complex object with many attributes, a representation of a user in the transaction context may only be a wrapper around the user ID. In the Send...
