Hexagonal architecture (also known as ports and adapters) is a software design pattern proposed by Alistair Cockburn in 2005 that isolates business logic from external I/O by placing all inputs and outputs at the edges of the system. The core application communicates exclusively through port interfaces, while adapters handle the concrete technology (databases, HTTP, messaging). The pattern has two sides: driving (inbound) adapters that call the core, and driven (outbound) adapters the core calls. Dependencies always point inward — the domain owns the interfaces, and infrastructure implements them. This enables swapping databases, UIs, or transport layers without touching business logic, and makes unit testing fast by substituting in-memory fakes. The post covers C# implementation examples, .NET solution structure, comparisons with layered/onion/clean architecture, DDD integration, domain-to-adapter mapping strategies, a Netflix real-world case study, and when not to use the pattern.

22m read timeFrom blog.ndepend.com
Post cover image
Table of contents
Hexagonal Architecture? More Like Ports and Adapters!Interfaces As PortsThe Two Sides: Driving and Driven AdaptersConcretions As AdaptersIt’s About Swappable ComponentsThe Dependency RuleAnd About the Test DriveThe UserRepo RevisitedStructuring a .NET Solution Around the HexagonHexagonal vs Layered, Onion, and Clean ArchitectureWhere Domain-Driven Design Fits InMapping Between the Domain and AdaptersA Real-World Example: Netflix StudioWhen NOT to Use Hexagonal ArchitectureCommon MisconceptionsFAQThat’s All There Is to It
30 Impressions