Domain-Driven Design¶
Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
Cited by¶
12 citations across 12 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Boundary
- Evans's Domain-Driven Design
This sourcebounded contexts — explicit boundaries around domain models within which a uniform ubiquitous language applies, with explicit integration rules at the boundary.
- Evans's Domain-Driven Design
- Design Patterns
- From this software foundation, pattern thinking generalized: Fowler's (2002) enterprise application patterns (Repository, Service Layer, Unit of Work, Active Record, Data Mapper), cloud-infrastructure patterns (Sidecar, Ambassador, Blue-Green Deployment, Canary Release), distributed-systems patterns (Circuit Breaker, Bulkhead, Saga, CQRS, Event Sourcing) catalogued in Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996), security-architecture patterns (Defense in Depth, Zero Trust, Threat Modeling), instructional-design patterns, organizational-change patterns (Fearless Change), domain-driven design patterns (Evans, 2003), and game-design patterns all follow Alexander's documented-solution template.
This sourcePattern-language treatment of domain modeling (Entity, Value Object, Aggregate, Repository, Bounded Context, Ubiquitous Language). Cited inline in §3 and §5 (tier B — supports the DDD-patterns generalization claim).
- From this software foundation, pattern thinking generalized: Fowler's (2002) enterprise application patterns (Repository, Service Layer, Unit of Work, Active Record, Data Mapper), cloud-infrastructure patterns (Sidecar, Ambassador, Blue-Green Deployment, Canary Release), distributed-systems patterns (Circuit Breaker, Bulkhead, Saga, CQRS, Event Sourcing) catalogued in Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996), security-architecture patterns (Defense in Depth, Zero Trust, Threat Modeling), instructional-design patterns, organizational-change patterns (Fearless Change), domain-driven design patterns (Evans, 2003), and game-design patterns all follow Alexander's documented-solution template.
Domain-specific¶
Mechanisms¶
- Adapter or Translation Shim
- Its central failure is that the "temporary" shim becomes permanent load-bearing infrastructure — because everything works, no one migrates, and the shim silently hardens into part of the contract, the very drift the archetype warns against.
This sourceIts whole value is being a boundary you own; its whole risk is forgetting it was meant to be temporary.
- Its central failure is that the "temporary" shim becomes permanent load-bearing infrastructure — because everything works, no one migrates, and the shim silently hardens into part of the contract, the very drift the archetype warns against.
- Adapter or Wrapper Layer
- The discipline that guards against this is to keep the contract explicit and the layer thin — an anti-corruption layer in the Domain-Driven Design sense, whose only job is translation, never behavior.
This sourceDefines the Domain-Driven Design Anticorruption Layer as an isolating boundary that translates between models.
- The discipline that guards against this is to keep the contract explicit and the layer thin — an anti-corruption layer in the Domain-Driven Design sense, whose only job is translation, never behavior.
- Adapter, Shim, or Translation Layer
- The disciplined version of this is Eric Evans's anti-corruption layer — a translation boundary whose whole job is to keep someone else's model from corrupting yours.
This sourceDefines an Anticorruption Layer as a translation boundary that protects one domain model from distortion by another.
- The disciplined version of this is Eric Evans's anti-corruption layer — a translation boundary whose whole job is to keep someone else's model from corrupting yours.
- Bounded Context or Domain Boundary Review
- The discipline that guards against it is to derive boundaries from the ubiquitous language and from domain experts who don't own the code, and to sanity-check that the proposed contexts would look the same if the company were reorganized tomorrow.
This sourceEvans links bounded contexts to coherent dialects of a ubiquitous language developed with domain expertise.
- The discipline that guards against it is to derive boundaries from the ubiquitous language and from domain experts who don't own the code, and to sanity-check that the proposed contexts would look the same if the company were reorganized tomorrow.
- Compatibility Layer
- The classic engineering name for a boundary that translates between a new model and a legacy one it must not let leak in is the anti-corruption layer.
This sourceDefines an anti-corruption layer as a translation boundary that protects a new domain model from leakage by a legacy model.
- The classic engineering name for a boundary that translates between a new model and a legacy one it must not let leak in is the anti-corruption layer.
- Domain Model
- Following the domain-driven design practice of building a shared model in a ubiquitous language,
This sourceDocuments domain-driven design practice of building a shared model in a ubiquitous language; every term on the diagram is a term everyone will use in meetings, tickets, and code.
- Following the domain-driven design practice of building a shared model in a ubiquitous language,
- Embedded Aggregate Document
- The honest guard is to embed only within a genuine aggregate
This sourceDefines an aggregate as a rooted cluster of domain objects treated as one unit for data changes and internal consistency.
- The honest guard is to embed only within a genuine aggregate
- Middleware
- Done well it is an anti-corruption layer — a translating boundary that keeps a clean modern system from being infected by a messy legacy model.
This sourceDefines an anticorruption layer as a translating boundary that prevents a legacy system's model from corrupting a new domain model.
- Done well it is an anti-corruption layer — a translating boundary that keeps a clean modern system from being infected by a messy legacy model.
- Service Boundary Definition
- This is the bounded context idea — a component with an explicit, self-consistent interface.
This sourceDefines a bounded context as an explicitly delimited part of a system within which a single model is kept consistent and its contacts with other models are made explicit.
- This is the bounded context idea — a component with an explicit, self-consistent interface.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 12 citations of this work carries a recorded support check.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 5 other ways.
- https://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780133052961 ×2
- https://books.google.com/books?id=hHBf4YxMnWMC ×1
- https://www.informit.com/store/domain-driven-design-tackling-complexity-in-the-heart-9780132181266 ×1
- https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/ ×1
- https://www.pearson.com/en-gb/subject-catalog/p/domain-driven-design-tackling-complexity-in-the-heart-of-software/P200000009375 ×1
Registry ID ref:0395203ed21c · see in the full table