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."