Laws of Software Engineering · Principle
Principle
Bounded Contexts
Different parts of a system can use the same word to mean different things. Draw an explicit boundary around each meaning and translate at the seam.
How to use it. When a word such as "customer", "order", or "account" means different things to different teams, you have found a boundary. Make it visible. Each context has its own model, vocabulary, and database schema. Translating between contexts is explicit work.
How it gets misused. Treated as a microservices technique. Bounded contexts are about meaning. You can have several inside a monolith, or one spread across several microservices. The boundary lives in the language and the model.
Related
- Principle Ubiquitous Language The people who build the software and the people who use it must use the same words to mean the same things. The vocabulary is the design.
- Pattern Hexagonal Architecture (Ports and Adapters) Put the domain at the centre. Surround it with ports (the contracts the domain offers) and adapters (the code that connects ports to the outside world).
Clusters
- The Code Design cluster - How to write code that survives change.
- The Interface Contracts cluster - What you promise, what you accept, what your users come to depend on.