You may have noticed that we did not actually talk about the actual business domain of our sample enterprise, but only considered its departments, which communicate with each other on a particular sub-domain. Consider that the HR department has its own people, processes, tools, and applications, which constitute its particular bounded context. Similarly, the Accounts and Regulatory departments have their own bounded contexts.

Here, in our sample scenario, the primary business processes are related to employee's documents in the HR department, which are validated and facilitated by the department of Regulatory Affairs. What we are looking at is a couple of bounded contexts talking or merging to achieve some business process; for such an interaction, we need context maps for the domain modeling, according to the Domain Driven Design (DDD) methodology.

Bounded context focuses on a single primary business domain, which gives all team members (business, IT, customers, and so on) shared and agreed understanding in a consistent manner. Thus, bounded context implementations become autonomous components. These components do not have dependencies on anything outside the bounded context, and they are capable of running together in isolation. Naturally, these are candidates encouraged to utilize the concepts of containerization. Fortunately, we will visit containerization in the later chapters of this book.

Context maps provide the relationship between bounded contexts, both in terms of business as well as technical implementation. These provide useful documentation to view and realize the integration between the different bounded contexts. Our sample business processes above can be considered as part of context maps if we are doing domain modeling using DDD.