hexagonal-architecturelisted

# hexagonal-architecture — voidcorp craftsman edition The domain decides; the world translates. Ports are interfaces the domain owns. Adapters wire ports to concrete technologies at the edge. Components do not touch the DB; services do not touch the framework router; use-cases orchestrate ports with no I/O of their own. The boundary makes the domain testable in isolation and replaceable infrastructure cheap. **Attribution**: see `.source` in this directory. Foundation: Cockburn 2005, Graca "Explicit Architecture," Bernhardt "Functional Core, Imperative Shell." --- ## Core terms | Term | Definition | |---|---| | **Domain** | The pure code that knows the business. Entities, aggregates, value objects, domain services. No I/O. | | **Port** | An interface owned by the domain that describes what the domain needs from the outside. Named by behavior (`OrdersPort.save`), not technology (`PostgresOrders` is an adapter). | | **Adapter** | An implementation of a port at the edge. Translates domain types to/from the external API. Thin. | | **Use-case** (application layer) | A thin function orchestrating ports for a specific user goal. Pure-by-default (no I/O), side effects via injected ports. Lives in `services/` (per `pack-monorepo` convention). | | **In-memory adapter** | A port adapter that runs in memory, owned by the domain test fixtures. Used by unit tests. Composes with `testing` skill's nullable infrastructure pattern. | --- ## Dependency direction ``` domain → ports