In sync with the domain model and code, the ubiquitous language constantly changes to represent both the evolving business and the architect’s growing understanding of the domain. However, the universal language cannot change indefinitely to incorporate 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 business domain area 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 additional terms are used to mean the same thing. When you see 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.

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 a model found in the solution space for a business subdomain. Its ubiquitous language uniquely identifies a bounded context; subsequently, outside the boundaries of the bounded context, the universal language changes. Wherever the ubiquitous language is the same, the context is the same.

Bounded contexts in DDD serve three primary purposes:

1. They prevent creating ambiguity and duplicating concepts.
2. Bounded contexts divide the domain into smaller pieces, thus simplifying the design of software modules.
3. A bounded context is an 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 ubiquitous language, 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 instances, 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 back office is the part where administrators feed data and set rules.

IMPORTANT ADVICE BY WEBSITE DEVELOPMENT SILVERDALE

Each bounded context has its independent implementation. A separate performance means having frameworks, technologies, methodologies, and architecture. In other words, it is perfectly acceptable in a DDD context in an extensive 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.