hexagonal-architecture
Applies hexagonal (ports & adapters) architecture. Use when designing application structure, separating domain from infrastructure, creating testable boundaries, or when user mentions ports, adapters, hexagonal, or clean architecture.
适合你，如果在设计应用结构时想隔离领域和基础设施
npx oh-my-skill add lexler/skill-factory/hexagonal-architecturecurl -fsSL https://oh-my-skill.com/install.sh | bash -s -- lexler/skill-factory/hexagonal-architecturenpx oh-my-skill verify lexler/skill-factory/hexagonal-architecture怎么用
商店整理自技能原文 · 版本 2eae60e · 表述以原文为准Claude会按照六边形架构原则指导你设计应用程序，帮你区分领域逻辑（六边形内部）与基础设施（外部适配器），定义端口和适配器，并提醒避免常见反模式。
当你提到“设计应用程序结构”“分离领域与基础设施”或提及ports、adapters、hexagonal等关键词时触发。
技能原文 SKILL.md
Hexagonal Architecture
The Core Decision Rule
To decide if something belongs inside or outside the hexagon, ask:
"Does it do I/O or run out-of-process?"
- No → Inside the hexagon (domain or application layer)
- Yes → Outside (adapter)
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.
Layer Responsibilities
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.
Naming Conventions
- Display/response:
*Viewor*Response→MemberView,OrderResponse - Incoming request:
*Request→CreateMemberRequest - Database entity:
*Dbo→MemberDbo - Domain → DTO:
static from(domain)→MemberView.from(member) - DTO → Domain:
as*()method →request.asMember()
Anti-Patterns
Brittle Interfaces
register(username, password) // Breaks when email required
Use wrapper objects that can evolve without breaking signatures.
Domain Scope Pollution
Third-party types (GoogleUser, StripePayment) leaking into domain. Keep external types in adapters; map to domain types at the boundary.
Use-Case Interdependencies
Use cases calling other use cases creates coupling. Each use case should be self-contained, orchestrating domain objects directly.
Anemic Domain
Entities as data bags with logic scattered in services. Business rules belong IN entities and value objects.
Premature Database Design
Designing schema before domain model. Domain model comes first; database adapter maps to it.
Over-Complicated Adapters
Adapters adding logic beyond translation. Adapters should be thin—just implement the port interface.
Testing Strategy
- Domain: Unit tests, no doubles needed (pure logic)
- Application: Unit tests with port doubles (fake repositories, stub notifiers)
- Adapters: Integration tests against real infrastructure (real database, real HTTP)
Ports give clean seams for test doubles. Test the domain exhaustively with fast unit tests; test adapters against real infrastructure sparingly.
When NOT to Use
- Small/simple projects, especially CRUD-based apps (overhead not worth it)