Design and implement DDD patterns (entities, value objects, aggregates, CQRS). Use when creating new domain objects, implementing bounded contexts, designing repository interfaces, or learning proper layer separation. For fixing existing Deptrac violations, use the deptrac-fixer skill instead.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Design and implement DDD patterns (entities, value objects, aggregates, CQRS). Use when creating new domain objects, implementing bounded contexts, designing repository interfaces, or learning proper layer separation. For fixing existing Deptrac violations, use the deptrac-fixer skill instead.
Implementing DDD Architecture
Context (Input)
Creating new entities, value objects, or aggregates
Implementing bounded contexts or modules
Designing repository interfaces and implementations
Need to understand CQRS pattern (Commands, Handlers, Events)
Code review for architectural compliance
Task (Function)
Design and implement rich domain models following DDD, hexagonal architecture, and CQRS patterns.
Success Criteria:
Domain entities remain framework-agnostic (no framework imports)
Business logic in Domain layer, not in Application handlers
make deptrac shows zero violations
Repository interfaces in Domain, implementations in Infrastructure
Core Principle
Rich Domain Models, Not Anemic
Business logic belongs in the Domain layer. Application layer orchestrates, Domain executes.
Architecture Planning: Existing Structure First
When writing architecture specs or proposing new classes for this repository, inspect the current source tree and deptrac.yaml before inventing directories.
Required workflow:
List existing directories for the bounded context, for example find src/Core/Customer -maxdepth 4 -type d | sort.
Check deptrac.yaml collectors for allowed Application, Domain, and Infrastructure directory names.
Reuse existing type directories whenever they already express the class responsibility.
Keep the rule one directory = one class type. Do not place policies, schedulers, registries, handlers, DTOs, and resolvers together in a broad feature bucket.
If a feature already exists through Repository, Collection, Resolver, EventSubscriber, or other established directories, extend that feature surface instead of creating a new umbrella directory such as Cache.
Introduce a new directory type only when no existing type fits, it is added to deptrac, and the architecture spec explains why the new type is necessary.
Do not propose ReadModel, Query, QueryHandler, Message, MessageHandler, Policy, Registry, or Scheduler directories unless the current repo already uses that directory type and deptrac collects it. Reads in the current Customer context are served by repositories, resolvers, processors, and DTOs rather than a separate read-model directory.
When a feature must be reusable across bounded contexts, put the generic command, worker, abstract base classes, DTOs, resolver interfaces, and metrics in Shared first. Keep each bounded context as a thin adapter that maps its domain events, tags, targets, policies, and repository warmup behavior into the shared contract. Do not route Customer-specific command payloads if the same queue and worker must later refresh other domains.
Do not add or keep static method declarations in project PHP files. Model behavior as injected services, listeners, factories, or regular value objects so dependencies remain explicit and testable.
HTTP request preconditions belong in kernel listeners, not static guards inside processors
Object creation belongs in factory services
Shared helpers should be injectable services
Run make forbid-static-methods or make psalm before finishing
