Bounded Context — Domain-Driven Design Vocabulary

Bounded context (Eric Evans, DDD): a boundary within which a single, consistent domain model applies. The same word may mean different things in different bounded contexts: 'Customer' in Sales BC (prospect + active customer) vs. 'Customer' in Support BC (anyone who has ever purchased). Bounded contexts make these differences explicit.

Ubiquitous language: developers and domain experts use the same vocabulary everywhere — in code (class names, method names), in conversations, in documentation. If the business says 'Order' and the code says 'PurchaseRecord', there is a translation layer that adds confusion. The goal: eliminate translation between business language and code.

A context map documents the relationships between bounded contexts: Upstream/Downstream (U produces the model, D adapts to it), Customer/Supplier (supplier commits to the customer's needs), Conformist (downstream simply conforms to upstream), Anti-Corruption Layer (downstream translates upstream model to protect its own model). Context maps prevent hidden coupling.

Anti-Corruption Layer: when integrating with an external system or legacy system whose model differs from yours, the ACL translates at the boundary. Your service works with its own clean model; the ACL handles translation to/from the external model. This prevents external model concepts from 'leaking' into and corrupting your domain model.

Domain events: 'OrderPlaced', 'PaymentReceived', 'InventoryReserved'. They record facts in the past tense — something that happened. Other bounded contexts subscribe to events they care about and react in their own domain model. Domain events enable loose coupling: the publishing context doesn't know or care who is listening.