architecture-patterns

Clean Architecture organizes code into concentric layers with inward-pointing dependencies: entities at the core, use cases in the middle, and adapters (UI, database, web) at the outer ring. This layering isolates business logic from frameworks, making systems testable and maintainable.

Both enforce inward dependencies, but Hexagonal Architecture emphasizes ports and adapters—defining interfaces for external concerns like databases or APIs. Clean Architecture is more prescriptive about layer count and names. Hexagonal fits well when you need flexible tooling swaps.

Domain-Driven Design models business logic using entities, value objects, aggregates, and repositories bounded by context. Define clear domain boundaries, map those to code structure, and ensure each bounded context owns its data and logic independently.

Refactor when a monolith becomes hard to test, deploy independently, or organize logically. Clean and Hexagonal Architectures let you separate concerns gradually, establish team standards, and enable independent feature scaling without rewriting the entire system at once.

Clean, Hexagonal, and Domain-Driven Design patterns apply to both monoliths and microservices. For microservices, each service follows the pattern internally; bounded contexts from DDD map naturally to service boundaries, reducing coupling and coordination overhead.

The Skill provides concrete directory structures for Clean Architecture (layers: entities, use cases, adapters) and Hexagonal (core domain, ports, adapters). Structure depends on your pattern choice; follow the provided examples to establish consistency and prevent layer violations.