SKILL.md
Clean Architecture, DDD, and Hexagonal Architecture
Use these related patterns to solve a concrete domain or dependency problem. This is an opinionated synthesis, not a mandatory folder layout. The user's explicit instructions take precedence over this skill's guidelines.
Choose the scope
Start from the requested behavior, existing domain model, and current dependencies. Preserve the project's language and architecture unless changing them is part of the task. Simple CRUD can remain simple; team size, entity count, and file length do not determine whether DDD is appropriate.
| Design question | Relevant pattern |
|---|---|
| What language and consistency rules describe the business? | DDD, bounded contexts, aggregates |
| Which way should source dependencies point? | Clean/Onion Architecture |
| How can the application use different interfaces or infrastructure? | Hexagonal ports and adapters |
| Do reads and writes need different models? | CQRS |
| Must state be reconstructed from an event history? | Event Sourcing |
If a business invariant is unknown, identify the specific missing rule and continue work that does not depend on it. Do not invent business behavior or require a discovery workshop for a local fix.