Business logic should not care whether a request came from HTTP, a CLI command, a message queue, or a scheduled job. It should also not care whether data is stored in PostgreSQL, MongoDB, Redis, or a file.

But in many codebases, those details slowly mix together. A controller starts making pricing decisions. A repository starts deciding refund rules. A use case imports an ORM model or a cloud SDK. After a while, changing a database, framework, or provider means touching business logic too.

Hexagonal architecture prevents that by keeping the application core separate. Business logic sits in the center. The outside world connects to it through clear boundaries called ports. Technology-specific code lives in adapters.

The practical goal is simple: keep business behavior independent from tools.

This chapter explains hexagonal architecture, ports and adapters, dependency direction, request flow, testing benefits, common mistakes, and when the pattern is worth using.