Reactive Systems Design Principles

Bounded Context

Reactive Programming

Photo by Anna Roguszczak from Pexels.

What is a bounded context?

In domain-driven design (DDD), bounded context is an important concept. In general, the business domains are often large and complicated. Bounded context gives us more information on how to deal with large domain models.

Before we go further, let’s understand what domain-driven development is and what the difference between a domain and a model is.

Domain-driven design (DDD)

The name “domain-driven design” comes from a book called “Domain-Driven Design: Tackling Complexity in the Heart of Software” by Eric Evans. Domain-driven design is a software development methodology that focuses on programming a domain model that has a deep understanding of a domain’s processes and rules.

Domain-driven design is a set of techniques, principles, and patterns used to aid in the development of complex systems where a lot of often-messy logic needs to be organized.

Domain-driven development focuses on three core principles:

1. Focus on the core domain and domain logic.
2. Complex designs should be based on domain models.
3. Constantly collaborate with domain experts in order to improve the application model and resolve any emerging domain-related issues.

Having said that, the goal of practising domain-driven design is to handle complex scenarios with a systematic approach in such a way that domain experts and the development team can collaborate effectively with minimum friction.

Domain

Domain refers to the subject or business area to which the application is intended to apply.

Model

The model is not the software. It represents our understanding of the domain. The software is the implementation of the model.

To deal with a large model, we can divide the model into different subdomains or zones, which we call a bounded context — it’s not easy to understand without breaking it down any further. Subdomains or bounded contexts usually map into some kind of a one-to-one relationship, and we will often see those terms used interchangeably.

For example, an organisation can be split into sales, inventory, and support departments, each operating within its context. By working in a bound or limited context, the work becomes easier and better organized.

Meaning may change between different bounded contexts

The meaning of a word may change dramatically from one bounded context to the next. For example, in a restaurant where we’re talking to a “server”, the term “order” has a very specific meaning.

• In a restaurant, when talking to a server, “order” has a very specific meaning: the customer is represented as a customer, whereas the restaurant is the supplier for that order.
• When speaking to the person who manages inventory for the restaurant, “order” means something completely different — here, the restaurant is the customer and there is some external supplier who is supplying the inventory supplies.