# Book Domain Driven Design Nano

> Domain-Driven Design (Eric Evans) — Minimal rules — essential one-liners only. Use when asked to apply Domain-Driven Design principles or review code against Domain-Driven Design standards.

- Skill: `yanacuti1121/book-domain-driven-design-nano` (Agent Skill)
- Install (CLI): `npx skillmds add yanacuti1121/book-domain-driven-design-nano`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yanacuti1121/book-domain-driven-design-nano/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: yanacuti1121 (https://skillmd.com/u/yanacuti1121)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/yanacuti1121/book-domain-driven-design-nano

---


# 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?