Why: the goal or problem

Testing a business rule should not require a live database or web server. External tools need replaceable connection points.

How: work toward a solution

  1. Fictional single process: R1, A17 unsaved. HTTP or CLI adapters call SaveArticle through its input port.
  2. SaveArticle validates IDs, then calls a memory or embedded-database adapter through SaveRepository. Both storage adapters depend on this application-owned port; the application imports neither implementation.
  3. Saved: 0 → 1 entries; repeat → 1. Empty IDs or failure before writing → 0; retry after correction.
Swap edge technology, keep application behavior

Illustrative example

Swap an edge, keep the application

R1 · A17 · initially unsaved

One process · dotted enclosure

1 · Driving adapters

  • HTTP
  • CLI

Imports → input port

2 · Application

Input portSaveArticle

Validate IDs, coordinate saving

Output port · owned hereSaveRepository

3 · Driven adapters

  • Memory
  • Embedded database

SaveRepository ← adapter imports

Runtime call

  1. HTTP / CLI
  2. SaveArticle
  3. SaveRepository
  4. Memory / Embedded database

Dashed path: the call reaches storage through the output port; Saved returns to the caller.

The application imports neither adapter implementation. Memory can stand in for the database during a test. Six sides are not six required parts.

  • Save → repeat: 0 → 1 → 1 entries; return Saved.
  • From empty: empty IDs or failure before writing → 0. Retry after correction.

HTTP / CLI and memory / embedded database are alternatives; no data migration is implied.

What: the concept

Hexagonal architecture connects an application through ports and technology-specific adapters. Six sides do not mandate six components. Cockburn

Ports add indirection. Clean dependency rules can organize internal policy.