Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From crafter
Architectural guidance for hexagonal (ports and adapters) patterns. Does not generate files — use scaffold for project generation. Use when designing application structure, separating domain from infrastructure, creating testable boundaries, or when user mentions ports, adapters, hexagonal, or clean architecture.
npx claudepluginhub agentpatterns/craft --plugin crafterHow this skill is triggered — by the user, by Claude, or both
Slash command
/crafter:hexagonal-architectureThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
To decide if something belongs inside or outside the hexagon, ask:
Guides applying Clean Architecture, Hexagonal Architecture, and Domain-Driven Design to structure systems with isolated business logic, layer boundaries, and dependency rules.
Designs, implements, and refactors hexagonal architecture (ports & adapters) with clear domain boundaries, dependency inversion, and testable use cases across TypeScript, Java, Kotlin, and Go.
Design, implement, and refactor Ports & Adapters systems with clear domain boundaries, dependency inversion, and testable use-case orchestration across TypeScript, Java, Kotlin, and Go services.
Share bugs, ideas, or general feedback.
To decide if something belongs inside or outside the hexagon, ask:
"Does it do I/O or run out-of-process?"
Critical: Consider ALL dependencies. A component's dependencies disqualify it even if the component itself doesn't do I/O. If it depends on Spring, a database driver, or any framework—it's outside.
Common misconception: The hexagon is NOT just the domain. The hexagon contains both domain AND application layers. Adapters sit outside.
┌─────────────────────────────────────────┐
│ ADAPTERS (outside) │
│ Web, CLI, Database, External APIs │
│ ┌───────────────────────────────────┐ │
│ │ APPLICATION SERVICES │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ DOMAIN │ │ │
│ │ └─────────────────────────────┘ │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────┘
Dependencies flow INWARD only
Domain — Business constraints (what CAN happen). Contains Entities, Value Objects, Domain Services.
Application — Orchestration (HOW things happen). Contains Use Cases, Application Services.
Adapters — Translation to/from external world. Contains Controllers, Repositories, API clients.
Domain defines ports (interfaces). Adapters implement them.
*View or *Response → MemberView, OrderResponse*Request → CreateMemberRequest*Dbo → MemberDbostatic from(domain) → MemberView.from(member)as*() method → request.asMember()register(username, password) // Breaks when email required
Use wrapper objects that can evolve without breaking signatures.
Third-party types (GoogleUser, StripePayment) leaking into domain. Keep external types in adapters; map to domain types at the boundary.
Use cases calling other use cases creates coupling. Each use case should be self-contained, orchestrating domain objects directly.
Entities as data bags with logic scattered in services. Business rules belong IN entities and value objects.
Designing schema before domain model. Domain model comes first; database adapter maps to it.
Adapters adding logic beyond translation. Adapters should be thin—just implement the port interface.
Ports give clean seams for test doubles. Test the domain exhaustively with fast unit tests; test adapters against real infrastructure sparingly.
Identify the bounded context — Name the module or service being designed. Establish its responsibility boundary before classifying any component.
Apply the Core Decision Rule to each component — For every candidate class or module, ask: "Does it do I/O or run out-of-process?" Inside (no) or adapter (yes).
Define ports (interfaces) in the domain layer — Each external dependency the domain or application needs must be expressed as an interface owned by the domain. No concrete infrastructure types cross this boundary.
Implement adapters outside the hexagon — Each port gets one or more adapter implementations in the infrastructure layer. Adapters are thin: they translate and delegate; they do not contain business logic.
Apply naming conventions — Name all DTOs, database entities, and mapping methods per the conventions in the Naming Conventions section above.
Check for anti-patterns — Review the Anti-Patterns section. Specifically look for: third-party types in the domain, use cases calling other use cases, and framework annotations inside the hexagon.
Verify testability — Domain and application layers must be unit-testable without real infrastructure. If a test requires a live database or HTTP call to test domain logic, a boundary has been violated.
Note: This skill provides architectural guidance. It does not scaffold files. Use the
scaffoldskill to generate the project structure. See references/disclaimer.md for scope boundaries.