#hexagonal

Pillar article sull'Architettura Esagonale (Ports and Adapters): come isolare la business logic da framework, database e servizi esterni.

Hexagonal Architecture The main idea is relatively simple: business rules should be at the...

Exponential backoff with jitter in Go belongs at the adapter, not the domain. Respect context deadlines, retry the right errors, keep the port clean.

Wrap a Go adapter with a fallback that serves stale cache when the downstream dies, and decide degrade-vs-fail per use case.

Wrap an outbound Go adapter with a circuit breaker. Closed, open, half-open states, and a use case that never learns the breaker exists.

Import slog in your Go domain and you weld a logging library to your business rules. A narrow port keeps it at the edge, where it belongs.

Kill time.Now() calls buried in Go business logic. A Clock port, a real adapter, a fake, and tests that stop flaking on midnight.

A concrete src/ tree for hexagonal PHP, the namespace-to-layer map, the allowed import directions, and the CI check that enforces them.

A vendor payload with string booleans and three date formats does not belong in your domain. Translate it once, at the adapter.

Fast unit tests on the domain, contract tests on the ports, a thin e2e layer. What to test where in a hexagonal PHP app, and what to stop testing.

Depend on ContainerInterface at the edge, build the graph in one place, and keep the domain container-free. The composition root pattern in PHP.

Auth, rate limits, and request IDs don't belong in your use cases. PSR-15 middleware is the HTTP edge where they live. Keep them there.