Architecture
Hexagonal
Hexagonal, or ports-and-adapters, architecture isolates core business logic behind interfaces (ports), with adapters for the database, web and external services plugged in at the edges. The domain never depends on frameworks, so you can swap infrastructure and test logic in isolation. The cost is more indirection and boilerplate up front.
Purpose
Hexagonal architecture — ports and adapters — puts the business logic at the centre, exposed and served only through interfaces (ports), with the messy outside world (database, HTTP, queues, third-party APIs) attached via adapters at the edges. The domain never imports the framework; the framework serves the domain.
When to Use It
Long-lived systems where infrastructure will change under a stable core: swapping databases or providers, adding a CLI or queue interface next to HTTP, and — most valuable day to day — testing business rules in isolation with in-memory adapters instead of spinning up infrastructure.
Trade-offs
The indirection costs boilerplate: interfaces, mappings between domain objects and persistence models, wiring. On small CRUD apps that tax buys little. The discipline pays off in proportion to how complex the domain is and how long the system lives.
Implementation
Define ports as interfaces owned by the domain (OrderRepository, PaymentGateway); implement adapters at the boundary (Postgres repository, Stripe client, Express controllers) and inject them. The dependency rule is absolute: source dependencies point inward, and the core compiles without any framework on the classpath.