Domain Driven Design
Walk a bounded-context backend design with a DDD checklist so entities, aggregates, and repositories stay consistent before you ship.
Overview
Domain-Driven Design is an agent skill most often used in Build (also Ship review) that applies a strategic and tactical DDD checklist to backend domain modeling.
Install
npx skills add https://github.com/yonatangross/orchestkit --skill domain-driven-designWhat is this skill?
- Strategic design: bounded contexts, context map relationships, ubiquitous language per context
- Tactical entities: UUIDv7 IDs, behavior-rich models, domain events on state changes
- Value objects: immutability, self-validation, equality without identity
- Aggregate rules: root-only access, invariants inside boundary, cross-aggregate references by ID
- Repository pattern: domain Protocol in domain layer, infra implementation returning entities not ORM models
- Strategic design section with bounded contexts and ubiquitous language
- Tactical sections covering entities, value objects, aggregates, and repositories
Adoption & trust: 542 installs on skills.sh; 183 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your API layers mix database shapes with business rules and no shared map of contexts, so every feature erodes the model.
Who is it for?
Indie SaaS or API builders introducing bounded contexts, event-friendly aggregates, and clean repository seams in Python/Postgres backends.
Skip if: Tiny scripts with no domain model, front-end-only prototypes, or teams that only need CRUD without context boundaries.
When should I use this skill?
Designing or reviewing backend domain models, context boundaries, aggregates, and repositories against DDD practice.
What do I get? / Deliverables
Documented contexts, ubiquitous language, and aggregate/repository boundaries your agent can verify against before merging backend work.
- Checked strategic design (context map, language glossary)
- Tactical model alignment (entities, VOs, aggregates, repository contracts)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the checklist targets domain models, aggregates, and repository boundaries in application code. Backend subphase covers strategic context maps and tactical patterns (entities, value objects, aggregates, repositories).
Where it fits
Split a single “orders” feature into sales vs fulfillment bounded contexts before prototyping APIs.
Implement aggregate roots that emit domain events instead of exposing mutable ORM models.
Run the repository checklist to ensure infra returns domain entities, not leaked persistence DTOs.
How it compares
Architecture checklist for domain modeling—not a scaffold generator or an ORM migration skill.
Common Questions / FAQ
Who is domain-driven-design for?
Solo developers and small teams shipping backend services who want DDD discipline without hiring a domain consultant.
When should I use domain-driven-design?
During Build backend when defining contexts and aggregates; during Ship review when checking PRs for anemic models or leaky repository returns; and during Validate scope when splitting a monolith idea into contexts.
Is domain-driven-design safe to install?
It is documentation-only checklist guidance with no runtime permissions—still review the Security Audits panel on this Prism page for the parent package.
SKILL.md
READMESKILL.md - Domain Driven Design
# Domain-Driven Design Checklist ## Strategic Design ### Bounded Contexts - [ ] Domain boundaries identified and documented - [ ] Context map shows relationships (ACL, Shared Kernel, etc.) - [ ] Each context has clear ownership - [ ] Ubiquitous language defined per context - [ ] Integration patterns chosen (events, API, shared DB) ### Ubiquitous Language - [ ] Domain terms documented in glossary - [ ] Code uses domain terminology (not technical jargon) - [ ] Team (dev + domain experts) agrees on terms - [ ] Terms are context-specific (not global) ## Tactical Design ### Entities - [ ] Identified by unique ID (prefer UUIDv7) - [ ] Equality based on ID, not attributes - [ ] Contains business logic (not anemic) - [ ] State changes through methods, not setters - [ ] Domain events emitted for significant changes - [ ] PostgreSQL 18: Using `gen_random_uuid_v7()` for IDs ### Value Objects - [ ] Immutable (`frozen=True` in dataclass) - [ ] Equality based on all attributes - [ ] Self-validating in `__post_init__` - [ ] No identity (no ID field) - [ ] Operations return new instances ### Aggregates - [ ] Aggregate root identified - [ ] All access through aggregate root - [ ] Invariants enforced within aggregate - [ ] References to other aggregates by ID only - [ ] Sized appropriately (not too large) ### Repositories - [ ] Interface defined in domain layer (Protocol) - [ ] Implementation in infrastructure layer - [ ] Returns domain entities (not ORM models) - [ ] Domain-specific query methods - [ ] Unit of Work for transaction management ### Domain Events - [ ] Events are immutable (frozen dataclass) - [ ] Events named in past tense (OrderPlaced, not PlaceOrder) - [ ] Events contain IDs, not full entities - [ ] Collection on entity, publishing in service layer - [ ] UUIDv7 for time-ordered event IDs ### Domain Services - [ ] Used for cross-entity operations - [ ] Stateless - [ ] Named with domain verbs (not technical) - [ ] Coordinates entities, doesn't replace their logic ## Layer Architecture ### Domain Layer - [ ] No infrastructure dependencies - [ ] Entities, value objects, domain events - [ ] Repository interfaces (Protocols) - [ ] Domain services ### Application Layer - [ ] Use cases / application services - [ ] Transaction management (Unit of Work) - [ ] Event publishing - [ ] DTO mapping ### Infrastructure Layer - [ ] Repository implementations - [ ] ORM models and mapping - [ ] External service clients - [ ] Anti-corruption layers ### Presentation Layer - [ ] API routes/controllers - [ ] Input validation (Pydantic) - [ ] Response formatting - [ ] No business logic ## Code Quality ### Naming - [ ] Classes named with domain terms - [ ] Methods use domain verbs - [ ] No technical jargon in domain layer - [ ] Consistent with ubiquitous language ### Testing - [ ] Domain logic unit tested - [ ] Repository implementations tested - [ ] Application services integration tested - [ ] Domain events verified ### Anti-Patterns Avoided - [ ] No anemic domain model - [ ] No business logic in controllers - [ ] No ORM models in domain layer - [ ] No circular dependencies between contexts - [ ] No UUIDv4 (use UUIDv7 for time-ordering) ## PostgreSQL 18 Specifics ### UUIDv7 Usage - [ ] `gen_random_uuid_v7()` as column default - [ ] Python: `uuid_utils.uuid7()` for app-generated IDs - [ ] Index on ID serves as ~created_at index - [ ] No separate created_at index needed for sorting ### Performance - [ ] UUIDv7 reduces index fragmentation - [ ] Recent records clustered together - [ ] Better cache locality for recent queries # Bounded Contexts ## Context Map ``` ┌─────────────────────────────────────────────────────────────────┐ │ E-Commerce System │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Identity │ │ Ca