Bounded Context (DDD)
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no, and while deptrac and phpstan are listed, they can only catch dependency violations after boundaries have been manually defined and encoded as rules — the original misuse (a single shared User model across billing/shipping/marketing) is invisible until a developer explicitly maps out the architecture. There is no automatic signal that bounded contexts are missing or wrong.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says 'draw explicit boundaries around each domain model', but the common_mistakes describe a shared domain model used everywhere. Separating a single monolithic User or domain model into context-specific models touches every layer — persistence, services, APIs, contracts — across multiple files and components. This is well beyond a single-component fix.
Closest to 'strong gravitational pull' (b7). The choice of how to define bounded contexts shapes every subsequent domain model decision, team structure, integration pattern, and service boundary. applies_to covers both web and cli contexts broadly, and tags include microservices and architecture. Every change to a domain concept must respect the established boundaries, making this a persistent and wide-reaching structural commitment.
Closest to 'serious trap' (t7). The misconception field explicitly states the canonical wrong belief: that a bounded context maps one-to-one to a microservice. This contradicts how many developers arriving from microservices literature think about it, and the common_mistakes reinforce that teams routinely share models across contexts or create too-fine-grained services. The concept contradicts intuitions formed from adjacent but different design patterns.
Also Known As
TL;DR
Explanation
A Bounded Context (Eric Evans) is the boundary within which a particular domain model is consistent and coherent. The same concept can exist in multiple contexts with different meanings — a Customer in the Sales context has different attributes and behaviour than a Customer in the Shipping context. Bounded Contexts map to separately deployable services in microservices, or to modules in a modular monolith. Context Maps describe the relationships between contexts: Shared Kernel, Customer/Supplier, Conformist, Anti-Corruption Layer, etc.
Diagram
flowchart TD
subgraph Ordering
O_CUST[Customer<br/>name, shippingAddress]
O_ORDER[Order<br/>lines, total]
end
subgraph Billing
B_CUST[Customer<br/>name, billingAddress]
B_INV[Invoice<br/>amount, dueDate]
end
subgraph Shipping
S_PARCEL[Parcel<br/>weight, trackingNo]
end
O_ORDER -->|integration event| B_INV
O_ORDER -->|integration event| S_PARCEL
INFO[Same word Customer means<br/>different things in each context]
style Ordering fill:#1f6feb,color:#fff
style Billing fill:#238636,color:#fff
style Shipping fill:#6e40c9,color:#fff
Common Misconception
Why It Matters
Common Mistakes
- One shared domain model across the entire application — changes to meet one context's needs break others.
- Not mapping between contexts explicitly — assuming User in the billing context is the same as User in the shipping context.
- Bounded contexts that are too small — a new microservice for every entity creates integration overhead without benefit.
- Not documenting context maps — which contexts exist and how they relate is critical institutional knowledge.
Code Examples
// Shared User model doing too many jobs across contexts:
class User {
// Auth context needs: id, email, passwordHash, roles
// Billing context needs: id, name, billingAddress, paymentMethods
// Shipping context needs: id, name, shippingAddresses
// One class serving all — changes for billing break auth
}// 'Customer' means different things in different contexts
// — model each separately rather than one bloated Customer class
// Sales context
namespace App\Sales;
class Customer { public string $name; public Money $creditLimit; }
// Support context
namespace App\Support;
class Customer { public string $name; public Ticket[] $openTickets; }
// Shipping context
namespace App\Shipping;
class Customer { public Address $shippingAddress; public string $preferredCarrier; }
// Contexts communicate via integration events, not shared objects
class CustomerRegistered { public function __construct(public int $id, public string $email) {} }