clean-ddd-hexagonallisted

# Clean Architecture + DDD + Hexagonal Backend architecture combining DDD tactical patterns, Clean Architecture dependency rules, and Hexagonal ports/adapters for maintainable, testable systems. ## When to Use (and When NOT to) | Use When | Skip When | |----------|-----------| | Complex business domain with many rules | Simple CRUD, few business rules | | Long-lived system (years of maintenance) | Prototype, MVP, throwaway code | | Team of 5+ developers | Solo developer or small team (1-2) | | Multiple entry points (API, CLI, events) | Single entry point, simple API | | Need to swap infrastructure (DB, broker) | Fixed infrastructure, unlikely to change | | High test coverage required | Quick scripts, internal tools | **Start simple. Evolve complexity only when needed.** Most systems don't need full CQRS or Event Sourcing. ## CRITICAL: The Dependency Rule Dependencies point **inward only**. Outer layers depend on inner layers, never the reverse. ``` Infrastructure → Application → Domain (adapters) (use cases) (core) ``` **Violations to catch:** - Domain importing database/HTTP libraries - Controllers calling repositories directly (bypassing use cases) - Entities depending on application services **Design validation:** "Create your application to work without either a UI or a database" — Alistair Cockburn. If you can run your domain logic from tests with no infrastructure, your boundaries are correct. ## Quick Decision Trees ### "Where does this code go?"