The ubiquitous language, in sync with the domain model and code, changes constantly to represent both the evolving business and the architect’s growing understanding of the domain. The ubiquitous language, however, cannot change indefinitely to incorporate more and more new concepts and slight variations of existing concepts. If you keep on doing that, you risk having a language with duplicates and creating a language that’s less rigorous than it should be.
This is where DDD introduces a new concept: the bounded context. The bounded context is the area of the business domain that gives any of the elements of the ubiquitous language a well-defined and unambiguous meaning.
Discovering bounded contexts
Especially in a large organization, you’ll find that it’s typical that the same term has different meanings for different people or that different terms are used to mean the same thing. When you find this happening, you have probably crossed the invisible boundaries of a subdomain. This probably means that the business domain you assumed to be one and indivisible is, in reality, articulated in subdomains. Also, read “HOW TO TRANSFORM INTO AN ADMIRED LEADER?“
Using subdomains and bounded contexts
In DDD, the problem space is the business domain. For this domain, you design a software domain model in the solution space. However, Website Development Silverdale specified clearly that the original domain sometimes might be too large to deal with effectively, so you then split it into multiple subdomains. When this happens in the problem space, you have a bounded context in the solution space.
Examining aspects of a bounded context
A bounded context is the model found in the solution space for a business subdomain. A bounded context is uniquely identified by its own ubiquitous language. Subsequently, outside the boundaries of the bounded context, the ubiquitous language changes. Wherever the ubiquitous language is the same, the context is the same.
Bounded contexts in DDD serve three primary purposes. First, they prevent creating ambiguity and duplicating concepts. Second, bounded contexts divide the domain into smaller pieces, thus simplifying the design of software modules. Finally, a bounded context is the ideal tool to integrate into the system legacy code or external components.
Detecting bounded contexts
In the DDD vision, a bounded context is an area of the application with its own ubiquitous language, its own independent implementation (for example, a domain model) and an interface to talk to other bounded contexts in the software. In some cases, and especially in large organizations, the number and relationships of bounded contexts often reflect the physical organization and departments. In other cases, bounded contexts are discovered along the way as the requirements are processed and differences in the originally unique languages are found.
Generally speaking, in the context of an online store application, the following are good candidates to become a bounded context:
- Store
- Accounting
- Delivery
- Backoffice
However, this is just a guideline. The actual partition results from analysis and depends on the specific context. In general, we at the Website Development Silverdale even say that any web application should be split into at least two contexts: the store and back office. The backoffice is the part where administrators feed data and set rules
IMPORTANT ADVICE BY WEBSITE DEVELOPMENT SILVERDALE
Each bounded context has its own independent implementation. An independent implementation means having frameworks, technologies, methodologies, and architecture. In other words, it is perfectly acceptable in a DDD context in a large system that one bounded context is implemented following the Domain Model pattern and another one according to a plain, two-tier, CRUD (Create, Read, Update, Delete)— oriented architecture.