StableArquitecturadomain-driven-design

Domain-Driven Design

Operationalizes DDD's core value: modeling software around the business domain's real language and boundaries — ubiquitous language, bounded contexts, aggregates, entities vs value objects — with explicit guidance that full tactical DDD is usually overkill below a certain complexity threshold.

dddbounded-contextubiquitous-languageaggregateentityvalue-object

Principios

· DD1 — One term, one meaning, per context. Code, docs, and conversation inside a bounded context use identical vocabulary; a naming mismatch between a developer and a domain expert is fixed immediately.
· DD2 — Draw bounded contexts around real organizational/semantic seams, not around technical convenience (a context per microservice-that-was-already-planned is backwards — model first, service boundaries follow).
· DD3 — Different contexts may define the same term differently, deliberately, with translation made explicit at the boundary (context map, anti-corruption layer) rather than forcing one universal model.
· DD4 — Value objects are immutable and defined by their attributes; prefer them over primitive obsession (Money, EmailAddress, DateRange instead of raw numbers/strings scattered with ad-hoc validation).
· DD5 — Entities are defined by identity, not attributes; equality compares identity, not field values.

Patrones

· The glossary test: ask a domain expert and a developer to independently define five core terms; mismatches point straight at translation-loss bugs waiting to happen.
· The "and" boundary test: if describing a context requires "and" for unrelated concerns (Sales *and* Support *and* Billing all as one "Customer" model), that's likely 2-3 bounded contexts wearing one name.
· Primitive obsession scan: grep for raw strings/numbers doing a value object's job (email as string validated in six different places) — candidates for DD4.
· Reach for full tactical DDD only in the core, complex subdomain — the one the business actually differentiates on. Supporting subdomains (user profile settings, admin tooling) rarely earn it.
· Context-map before microservices. If a team can't draw bounded contexts on a whiteboard, splitting into services will just distribute the confusion over a network.

Riesgos

· Ver anti-patrones específicos del dominio en el pack.

Checklist

[ ] Domain-layer naming matches the ubiquitous language / a maintained glossary. (DR1)
[ ] Invariants enforced inside aggregate roots, not left to external calling code. (DR5)
[ ] Cross-aggregate references are by ID, not direct object reference. (DR4)
[ ] External system models don't leak directly into the domain layer (anti-corruption layer present). (DR7)
[ ] Value objects immutable with structural equality; entities with identity-based equality. (DR2, DR3)
[ ] Cross-aggregate/cross-context effects use domain events, not reaching into another aggregate's internals. (DR6)

Fuentes

En la bibliografía AKOS

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

Explorar todas las fuentes →