Most architecture discussions start with boxes and arrows on a whiteboard. This one starts with a question: can you test your business logic without starting a database, a web server, or an external service?
If the answer is no, your architecture is in the way.
Hexagonal architecture — also known as ports and adapters — puts your business logic at the centre and pushes infrastructure to the edges. The database is an adapter. The web framework is an adapter. The email service is an adapter. Your business rules do not know or care about any of them. They talk through interfaces, and the interfaces do not mention SQL, HTTP, or JSON.
This course teaches you how to design systems where testability is not an afterthought but a consequence of good architecture.
Morning — Ports, adapters, and the centre
You start by separating business logic from infrastructure in a working Java application. You define ports — interfaces that describe what the application needs — and adapters that implement them.
You will build an in memory adapter and a real adapter for the same port. The in memory adapter is fast and deterministic. It is enough for every test that exercises business logic. The real adapter talks to a database. It must be tested, but only enough to know it satisfies the same contract. Fast where speed matters, real where confidence matters.
By mid-morning your business logic has zero dependencies on frameworks, databases, or external services. Your tests run in milliseconds.
Afternoon — Living with the architecture
Good architecture must survive contact with real development. In the afternoon you work through the scenarios that break most designs: a new feature that crosses boundaries, a framework upgrade, a third-party service that changes its API.
You will see how hexagonal architecture absorbs these changes. The adapter changes. The port stays the same. The business logic never notices. You will also learn when this architecture is overkill — because not every application needs it, and knowing when to keep things simple is as important as knowing when to invest in structure.
Optional day 2 — Deep dive
The second day brings your own codebase to the table. You apply hexagonal architecture to real code — identifying the boundaries, extracting ports, building adapters, and migrating existing infrastructure dependencies step by step. This is where theory meets the mess of a living system, and where you learn how to refactor towards testability without rewriting everything at once.
What you bring home
An architecture where your business logic is testable in isolation, your infrastructure is replaceable, and your tests are fast enough that nobody is tempted to skip them. Design in service of delivery, not in service of diagrams.