yanacuti1121 OBEY Domain-Driven Design by Eric Evans
When to use
Use as always-on DDD guidance when domain language, invariants, lifecycle, or integration boundaries affect implementation choices.
Primary bias to correct
Generic plumbing and DDD terminology are not a domain model.
Decision rules
- Keep model, code, tests, documents, and team language aligned inside each Bounded Context.
- Make business behavior explicit in model code, not hidden in controllers, persistence, jobs, scripts, or framework glue.
- Refine Ubiquitous Language when terms are fuzzy, and use only models that solve the problem and can be implemented.
- Use tactical patterns for domain meaning: Entities for identity, Value Objects for value, Services for homeless operations, and Modules for conceptual cohesion.
- Treat Aggregates as consistency and lifecycle boundaries; expose roots only and protect invariants inside the boundary.
- Hide complex creation and persistence behind Factories and Repositories; design for the model first and storage second.
- Define context boundaries and relationships explicitly before sharing terms, data, or behavior across systems.
- Protect the Core Domain from generic subdomains, reusable mechanisms, infrastructure, framework pressure, and foreign models.
- Refactor toward deeper insight: make important constraints, policies, processes, and calculations explicit domain concepts.
- Test invariants, invalid construction, lifecycle transitions, and boundary translations in the Ubiquitous Language.
Trigger rules
- Fuzzy or inconsistent terms trigger language refinement and code renaming.
- Procedural business rules in orchestration, SQL, jobs, or serializers trigger moving behavior into the model.
- Sprawling transactions or cross-module changes trigger Aggregate and context-boundary review.
- Foreign model, schema, API, or legacy pressure triggers translation or an explicit Conformist choice.
- Supporting mechanisms obscuring distinctive value trigger Core Domain distillation.
Final checklist
- Domain behavior in the model?
- One language per context?
- Invariants protected by roots and values?
- Integration relationship explicit?
- Domain tests cover invalid states and translations?
- Core Domain still visible?