Strategic Domain-Driven Design: Bounded Contexts
Bounded Contexts define the boundaries within which a domain model and its language apply. In this series, we explore how to identify meaningful boundaries, design focused models, and use them to build software that is easier to understand, evolve, and maintain.
Uunderstanding the business is only part of the challenge. We also need to decide how to represent that knowledge in software. A model that works well for one problem may be confusing, overly complex, or even misleading when applied to another.
Bounded Contexts help us address this challenge by defining where a particular model applies and where its concepts, rules, and language remain consistent. They allow us to represent different perspectives of the same business without forcing everything into one universal model.
This series explores how to identify and design Bounded Contexts, how they relate to subdomains and Ubiquitous Language, and how their boundaries influence software architecture.
Articles in this Series
Subdomains vs. Bounded Contexts: similar boundaries, different purposes
Subdomains and Bounded Contexts both introduce boundaries, but they serve different purposes. This article explains the difference between understanding business problems in the problem space and defining model boundaries in the solution space.
Bounded Contexts Are Not Services
A Bounded Context does not automatically mean a separate microservice.
This article explains why domain model boundaries and runtime or deployment boundaries solve different problems. We explore how Bounded Contexts can guide architectural decisions in both microservices and modular monoliths, and why preserving meaningful domain boundaries matters more than blindly mapping every context to a service.