Sign in to track progress and bookmarks.
In a large system, the same word can mean different things. A Bounded Context is a linguistic boundary where a model is strictly defined.
In the **Sales Context**, a 'Product' has a price and a marketing description.
In the **Shipping Context**, a 'Product' only has a weight and dimensions.
In the **Inventory Context**, a 'Product' only has a SKU and a count.
If you try to build one giant Product class with 100 properties to satisfy everyone, you've created a monster. Instead, create three different models in three different Bounded Contexts.
Bounded Contexts are the 'Grand Blueprint' for Microservices. Usually, one Bounded Context = One Microservice. This is the strategic part of DDD that helps you split your monolith into logical, independent pieces based on business meaning, not just technical convenience.
Q: "How do I communicate between contexts?"
Architect Answer: "Integration. You can use **Integrations Patterns** like 'Customer/Supplier' or use an 'Anti-Corruption Layer' (ACL). An ACL is a service that translates the data from an external, messy system into your clean, local domain model. It prevents the 'corruption' of your domain logic by external legacy code."
Quizzes linked to this course—pass to earn certificates.
On this page
1. One Word, Two Meanings 2. Microservices Connection 3. Architect Insight