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.

Generic plumbing and DDD terminology are not a domain model.

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.

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.