clean-ddd-hexagonal

Name: clean-ddd-hexagonal
Author: ccheney

3.9kinstalls3forks

How to install clean-ddd-hexagonal?

ccheney/robust-skills/clean-ddd-hexagonal

$npx -y skills add ccheney/robust-skills --skill clean-ddd-hexagonal

Installs into the current project.

Summary

Proactively apply when designing APIs, microservices, or scalable backend structure. Triggers on DDD, Clean Architecture, Hexagonal, ports and adapters, entities, value objects, domain events, CQRS, event sourcing, repository pattern, use cases, onion architecture, outbox pattern

Files · 1

View on GitHub

SKILL.md

1	# Clean Architecture + DDD + Hexagonal
2
3	Backend architecture combining DDD tactical patterns, Clean Architecture dependency rules, and Hexagonal ports/adapters for maintainable, testable systems.
4
5	This skill is an opinionated synthesis of several related architecture traditions. It is not a single canonical architecture model. Use the original source that matches the design question you are answering: DDD for domain modeling, Hexagonal Architecture for ports/adapters, Clean Architecture for dependency direction, Onion Architecture for domain-centered layering, and CQRS/Event Sourcing only for specific read/write or temporal requirements.
6
7	## When to Use (and When NOT to)
8
9	\| Use When \| Skip When \|
10	\|----------\|-----------\|
11	\| Complex business domain with many rules \| Simple CRUD, few business rules \|
12	\| Long-lived system (years of maintenance) \| Prototype, MVP, throwaway code \|
13	\| Team of 5+ developers \| Solo developer or small team (1-2) \|
14	\| Multiple entry points (API, CLI, events) \| Single entry point, simple API \|
15	\| Need to swap infrastructure (DB, broker) \| Fixed infrastructure, unlikely to change \|
16	\| High test coverage required \| Quick scripts, internal tools \|
17
18	Start simple. Evolve complexity only when needed. Most systems don't need full CQRS or Event Sourcing.
19
20	## Pattern Boundaries
21
22	\| Pattern \| Primary Question \| Use It For \| Do Not Treat As \|
23	\|---------\|------------------\|------------\|-----------------\|
24	\| DDD \| How do we model a complex business domain? \| Ubiquitous language, bounded contexts, aggregates, value objects \| A folder structure by itself \|
25	\| Hexagonal Architecture \| How does the application interact with the outside world? \| Ports, driver adapters, driven adapters, testable application core \| A mandate for six sides or one exact package layout \|
26	\| Clean Architecture \| Which direction should dependencies point? \| Inward dependency rule, use case boundaries, framework independence \| A universal four-folder template \|
27	\| Onion Architecture \| How do we keep the domain model central? \| Domain-centered layers and dependency inversion \| A separate requirement when Clean/Hexagonal already solve the local problem \|
28	\| CQRS \| Do reads and writes need different models? \| Bounded contexts with divergent read/write workloads \| A default application architecture \|
29	\| Event Sourcing \| Do we need state from a complete event history? \| Audit, temporal queries, replayable workflows \| A persistence default for CRUD systems \|
30
31	## CRITICAL: The Dependency Rule
32
33	Dependencies point inward only. Outer layers depend on inner layers, never the reverse.
34
35	```
36	Infrastructure → Application → Domain
37	(adapters) (use cases) (core)
38	```
39
40	Violations to catch:
41	- Domain importing database/HTTP libraries
42	- In this architecture style, controllers calling repositories directly instead of application use cases
43	- Entities depending on application services
44
45	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.
46
47	## Quick Decision Trees
48
49	### "Where does this code go?"
50
51	```
52	Where does it go?
53	├─ Pure business logic, no I/O → domain/
54	├─ Orchestrates domain + has side effects → application/
55	├─ Talks to external systems → infrastructure/
56	├─ Defines HOW to interact (interface) → port (domain or application)
57	└─ Implements a port → adapter (infrastructure)
58	```
59
60	Sharp edges — the placements LLMs most often get wrong:
61
62	\| Code \| Layer \| Why \|
63	\|------\|-------\|-----\|
64	\| Business invariant ("order needs items to confirm") \| Domain (entity method) \| It's a rule, not orchestration \|
65	\| Input format validation (JSON shape, required fields) \| Adapter (controller/DTO) \| Protocol concern, not business rule \|
66	\| Transaction begin/commit \| Application \| Use case = transaction boundary \|
67	\| ORM entity / table model \| Infrastructure \| Map to domain objects; never let ORM entities BE domain entities \|
68	\| Domain ↔ DB mapping \| Infrastructure (mapper) \| Persistence detail \|
69	\| Authorization ("is user allowed?") \| Application (policy) or adapter middleware \| Domain stays auth-agnostic; encode role RULES in domain only if they're business rules \|
70	\| Clock, UUID generation \| Port in domain/application; adapter in infrastructure \| Keeps domain determinist

People who liked this also viewed

6 picks

Type

clean-ddd-hexagonal

3.9kinstalls3forks

View on GitHub

How to install clean-ddd-hexagonal?

ccheney/robust-skills/clean-ddd-hexagonal

$npx -y skills add ccheney/robust-skills --skill clean-ddd-hexagonal

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Clean Architecture + DDD + Hexagonal
2
3	Backend architecture combining DDD tactical patterns, Clean Architecture dependency rules, and Hexagonal ports/adapters for maintainable, testable systems.
4
5	This skill is an opinionated synthesis of several related architecture traditions. It is not a single canonical architecture model. Use the original source that matches the design question you are answering: DDD for domain modeling, Hexagonal Architecture for ports/adapters, Clean Architecture for dependency direction, Onion Architecture for domain-centered layering, and CQRS/Event Sourcing only for specific read/write or temporal requirements.
6
7	## When to Use (and When NOT to)
8
9	\| Use When \| Skip When \|
10	\|----------\|-----------\|
11	\| Complex business domain with many rules \| Simple CRUD, few business rules \|
12	\| Long-lived system (years of maintenance) \| Prototype, MVP, throwaway code \|
13	\| Team of 5+ developers \| Solo developer or small team (1-2) \|
14	\| Multiple entry points (API, CLI, events) \| Single entry point, simple API \|
15	\| Need to swap infrastructure (DB, broker) \| Fixed infrastructure, unlikely to change \|
16	\| High test coverage required \| Quick scripts, internal tools \|
17
18	Start simple. Evolve complexity only when needed. Most systems don't need full CQRS or Event Sourcing.
19
20	## Pattern Boundaries
21
22	\| Pattern \| Primary Question \| Use It For \| Do Not Treat As \|
23	\|---------\|------------------\|------------\|-----------------\|
24	\| DDD \| How do we model a complex business domain? \| Ubiquitous language, bounded contexts, aggregates, value objects \| A folder structure by itself \|
25	\| Hexagonal Architecture \| How does the application interact with the outside world? \| Ports, driver adapters, driven adapters, testable application core \| A mandate for six sides or one exact package layout \|
26	\| Clean Architecture \| Which direction should dependencies point? \| Inward dependency rule, use case boundaries, framework independence \| A universal four-folder template \|
27	\| Onion Architecture \| How do we keep the domain model central? \| Domain-centered layers and dependency inversion \| A separate requirement when Clean/Hexagonal already solve the local problem \|
28	\| CQRS \| Do reads and writes need different models? \| Bounded contexts with divergent read/write workloads \| A default application architecture \|
29	\| Event Sourcing \| Do we need state from a complete event history? \| Audit, temporal queries, replayable workflows \| A persistence default for CRUD systems \|
30
31	## CRITICAL: The Dependency Rule
32
33	Dependencies point inward only. Outer layers depend on inner layers, never the reverse.
34
35	```
36	Infrastructure → Application → Domain
37	(adapters) (use cases) (core)
38	```
39
40	Violations to catch:
41	- Domain importing database/HTTP libraries
42	- In this architecture style, controllers calling repositories directly instead of application use cases
43	- Entities depending on application services
44
45	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.
46
47	## Quick Decision Trees
48
49	### "Where does this code go?"
50
51	```
52	Where does it go?
53	├─ Pure business logic, no I/O → domain/
54	├─ Orchestrates domain + has side effects → application/
55	├─ Talks to external systems → infrastructure/
56	├─ Defines HOW to interact (interface) → port (domain or application)
57	└─ Implements a port → adapter (infrastructure)
58	```
59
60	Sharp edges — the placements LLMs most often get wrong:
61
62	\| Code \| Layer \| Why \|
63	\|------\|-------\|-----\|
64	\| Business invariant ("order needs items to confirm") \| Domain (entity method) \| It's a rule, not orchestration \|
65	\| Input format validation (JSON shape, required fields) \| Adapter (controller/DTO) \| Protocol concern, not business rule \|
66	\| Transaction begin/commit \| Application \| Use case = transaction boundary \|
67	\| ORM entity / table model \| Infrastructure \| Map to domain objects; never let ORM entities BE domain entities \|
68	\| Domain ↔ DB mapping \| Infrastructure (mapper) \| Persistence detail \|
69	\| Authorization ("is user allowed?") \| Application (policy) or adapter middleware \| Domain stays auth-agnostic; encode role RULES in domain only if they're business rules \|
70	\| Clock, UUID generation \| Port in domain/application; adapter in infrastructure \| Keeps domain determinist

People who liked this also viewed

6 picks

Type