hexagonal-architecture
Helps your agent design systems using hexagonal architecture. Clearly separates business rules from other system parts, aiding testing and maintenance.
What it does
This skill helps organize your program's code so that the core business logic is separated from technical details like databases or user interfaces. This makes the code easier to understand, test, and modify.
When to use it
- ✓When starting a new project that needs to be easy to maintain.
- ✓When current code is messy and mixes business rules with technology.
- ✓If you need to connect your program to different systems (like a database or API) without changing the core logic.
Example of what to ask your AI
“How can I organize my code so that business logic doesn't depend on which database we use?”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
It works by defining 'ports' (contracts) for external interactions and 'adapters' that implement these ports. The core program logic uses the ports, and the adapters handle the technical details.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add affaan-m/ECC --skill hexagonal-architectureOr download just the file:
curl -L https://raw.githubusercontent.com/affaan-m/ECC/main/pi/core/skills/hexagonal-architecture/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Hexagonal Architecture
Hexagonal architecture (Ports and Adapters) keeps business logic independent from frameworks, transport, and persistence details. The core app depends on abstract ports, and adapters implement those ports at the edges.
When to Use
- Building new features where long-term maintainability and testability matter.
- Refactoring layered or framework-heavy code where domain logic is mixed with I/O concerns.
- Supporting multiple interfaces for the same use case (HTTP, CLI, queue workers, cron jobs).
- Replacing infrastructure (database, external APIs, message bus) without rewriting business rules.
Use this skill when the request involves boundaries, domain-centric design, refactoring tightly coupled services, or decoupling application logic from specific libraries.
Core Concepts
- Domain model: Business rules and entities/value objects. No framework imports.
- Use cases (application layer): Orchestrate domain behavior and workflow steps.
- Inbound ports: Contracts describing what the application can do (commands/queries/use-case interfaces).
- Outbound ports: Contracts for dependencies the application needs (repositories, gateways, event publishers, clock, UUID, etc.).
- Adapters: Infrastructure and delivery implementations of ports (HTTP controllers, DB repositories, queue consumers, SDK wrappers).
- Composition root: Single wiring location where concrete adapters are bound to use cases.
Outbound port interfaces usually live in the application layer (or in domain only when the abstraction is truly domain-level), while infrastructure adapters implement them.
Dependency direction is always inward:
- Adapters -> application/domain
- Application -> port interfaces (inbound/outbound contracts)
- Domain -> domain-only abstractions (no framework or infrastructure dependencies)
- Domain -> nothing external
How It Works
Step 1: Model a use case boundary
Define a single use case with a clear input and output DTO. Keep transport details (Express req, GraphQL context, job payload wrappers) outside this boundary.
Step 2: Define outbound ports first
Identify every side effect as a port:
- persistence (
UserRepositoryPort) - external calls (
BillingGatewayPort) - cross-cutting (
LoggerPort,ClockPort)
Ports should model capabilities, not technologies.
Step 3: Implement the use case with pure orchestration
Use case class/function receives ports via constructor/arguments. It validates application-level invariants, coordinates domain rules, and returns plain data structures.
Step 4: Build adapters at the edge
- Inbound adapter converts protocol input to use-case input.
- Outbound adapter maps app contracts to concrete APIs/ORM/query builders.
- Mapping stays in adapters, not inside use cases.
Step 5: Wire everything in a composition root
Instantiate adapters, then inject them into use cases. Keep this wiring centralized to avoid hidden service-locator behavior.
Step 6: Test per boundary
- Unit test use cases with fake ports.
- Integration test adapters with real infra dependencies.
- E2E test user-facing flows through inbound adapters.
Architecture Diagram
flowchart LR
Client["Client (HTTP/CLI/Worker)"] --> InboundAdapter["Inbound Adapter"]
InboundAdapter -->|"calls"| UseCase["UseCase (Application Layer)"]
UseCase -->|"uses"| OutboundPort["OutboundPort (Interface)"]
OutboundAdapter["Outbound Adapter"] -->|"implements"| OutboundPort
OutboundAdapter --> ExternalSystem["DB/API/Queue"]
UseCase --> DomainModel["DomainModel"]
Suggested Module Layout
Use feature-first organization with explicit boundaries:
src/
features/
orders/
domain/
Order.ts
OrderPolicy.ts
application/
ports/
inbound/
CreateOrder.ts
outbound/
OrderRepositoryPort.ts
PaymentGatewayPort.ts
use-cases/
CreateOrderUseCase.ts
adapters/
inbound/
http/
createOrderRoute.ts
outbound/
postgres/
PostgresOrderRepository.ts
stripe/
StripePaymentGateway.ts
composition/
ordersContainer.ts
TypeScript Example
Port definitions
export interface OrderRepositoryPort {
save(order: Order): Promise<void>;
findById(orderId: string): Promise<Order | null>;
}
export interface PaymentGatewayPort {
…
FAQ
What are 'ports' and 'adapters'?
Ports are like contracts that define what the program needs to do or what external services it will use. Adapters are the concrete implementations of these contracts, handling communication with databases, APIs, etc.
Why is it called 'hexagonal architecture'?
The name comes from the idea that the core business logic can be seen as a hexagon, with ports on each side to connect to different adapters (like a keyboard, monitor, etc., on a computer).
Is this more complicated to implement?
It might seem a bit more complex at first, but in the long run, it makes development and maintenance much easier and safer, especially in large projects.
Details
Original description by the author
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. Use when introducing or refactoring toward Ports and Adapters, or when domain logic has become entangled with I/O.
repo: affaan-m/ECC
Popularity
- GitHub stars
- 280k
- Ranking position
- #63
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
accessibility
Helps your agent create interfaces that everyone can use. Ensures websites and apps work well for people with disabilities, like those who are blind or have reduced mobility.
affaan-m/ECC
agent-architecture-audit
Makes your agent check if everything is working correctly. It finds and fixes problems in AI systems, ensuring they perform as expected.
affaan-m/ECC
agent-eval
Helps your agent compare different AI coding tools. It measures which one is faster, cheaper, and more reliable for specific tasks.
affaan-m/ECC
agent-harness-construction
Makes your agent better understand how to perform tasks. It optimizes the tools and instructions the agent uses to increase its chances of success.
affaan-m/ECC
Similar skills
karpathy-guidelines
Helps your agent write better code by avoiding common mistakes. It's useful for ensuring code is simple, clear, and easy to verify.
multica-ai/andrej-karpathy-skills
skill-creator
Lets the agent create, modify, and optimize skills. Useful for testing skill performance and improving their accuracy.
anthropics/skills
ponytail-debt
Lists all code shortcuts ('shortcut:') left for later. It helps to see what still needs to be fixed in the project.
DietrichGebert/ponytail