Hexagonal & Clean Architecture
Put the domain at the center; push frameworks to the edge.
The architecture that makes Dependency Inversion the shape of the whole system: dependencies point inward toward a pure domain, and databases, web frameworks, and message brokers are pluggable details at the edge. Ports and adapters, the layers of Clean Architecture, keeping the core framework-free, testing it in isolation - and a pragmatic verdict on when the structure is worth its cost.
Lessons in this stage
- 01
The Dependency Rule
AdvancedThe one idea behind hexagonal, onion, and clean architecture: source-code dependencies point only inward, toward the domain - so the core never depends on the database or web layer.
15 min - 02
Ports & Adapters
AdvancedHexagonal architecture in concrete terms: ports are interfaces the domain owns, adapters are implementations at the edge - and the driving vs. driven distinction.
16 min - 03
The Layers of Clean Architecture
AdvancedEntities, use cases, interface adapters, frameworks & drivers - the concentric circles, and how a use-case interactor orchestrates a single application operation.
15 min - 04
Keeping the Domain Pure
AdvancedNo JPA or Spring annotations in the core: mapping between domain models and persistence/DTOs at the boundary, and honestly weighing the mapping cost against the payoff.
15 min - 05
Testing a Hexagonal App
AdvancedThe real payoff: test the domain and use cases in memory with fake adapters, no Spring context or database - fast, focused tests that align with the testing pyramid.
14 min - 06
Is It Worth It?
IntermediateWhen full hexagonal pays off versus a simpler layered design, the middle grounds, and how you'd refactor ledger-legacy toward the domain-at-the-center shape incrementally.
13 min