Hexagonal Architecture in Go: Why Your Service's Business Logic Should Know Nothing About HTTP

You've seen it happen. Maybe you caused it. A Go service starts as a clean main.go with a few handlers. Six months later, the handler that was 40 lines is 400. The SQL queries live inside HTTP handlers. The business logic imports database/sql . The test suite takes six minutes because every test needs a running PostgreSQL. Someone suggests a refactor. A Jira ticket gets created. Nobody assigns it. This isn't because Go developers are bad. It's because Go gives you freedom without structure. No mandatory base classes. No framework telling you where things go. Freedom without a plan leads to spaghetti. The One Rule That Fixes It Hexagonal architecture (ports and adapters) comes down to one rule: Dependencies always point inward. The domain knows nothing about infrastructure. Your Order entity doesn't know it's stored in PostgreSQL. Your OrderService doesn't know it's called from an HTTP handler. Your discount calculation doesn't know the coupon code came from a JSON body. // The domain d