Managing Multiple Bounded Contexts
Many applications consist of more than one domain, or, to stick with Domain-Driven Design language, more than one bounded context. The term “bounded context” tells us that there should be boundaries between the different domains. If we don’t have boundaries between different domains, there are no restrictions on dependencies between classes in these domains. Eventually, dependencies will grow between the domains, coupling them together. This coupling means that the domains can no longer evolve in isolation, but can only evolve together. We could just as well not have separated our code into different domains in the first place!
The whole reason to separate code into different domains is so that these domains can evolve in isolation. This is an application of the Single Responsibility Principle, discussed in Chapter 3, Inverting Dependencies. Only, this time, we’re not talking about the responsibilities of a single class...
