Architectural styles
On this page 8 topics
Overview
Topics
- Layered
- hexagonal
- clean architecture
- modular monolith
Learn first
3 h of practice (estimate)
Learning outcomes
- Compare layered, hexagonal (ports and adapters), and clean architecture, and state what each protects.
- Restructure a layered service so the domain does not depend on frameworks or infrastructure.
- Design a modular monolith with enforced module boundaries and explicit module APIs.
- Choose a style for a given team size, domain complexity, and change rate.
Lessons
Lab and exercises
Lab
MID-059-LAB1 · Hexagonal Shop
Outcomes: 1–3 · Time: ~3 h
- Restructure Shop into modules (
catalog,orders,inventory,payments), each withapiandinternalpackages. - In
orders, move the domain to plain Java with outbound portsOrderRepositoryandPaymentGateway; implement JPA and payment adapters. - Add ArchUnit tests: the domain has no
org.springframework..orjakarta.persistence..imports; modules only use each other'sapi. - Add a second payment adapter (fake) and select it by profile.
Acceptance: the payment adapter can be swapped without touching the domain; ArchUnit tests pass and fail when a violation is introduced.
Exercises (assessment: architecture-style comparison for a scenario; five exercises)
| ID | Outcome | Task |
|---|---|---|
| MID-059-EX01 | 1 | Write one paragraph each on what layered, hexagonal, and clean architecture protect and what they cost. |
| MID-059-EX02 | 2 | Given a service that injects JpaRepository and RestTemplate into business logic, list the dependencies to invert and name the ports. |
| MID-059-EX03 | 2 | Write an ArchUnit rule that forbids ..domain.. from depending on org.springframework... |
| MID-059-EX04 | 3 | Sketch a modular monolith for a booking system with three modules; define each module's public API and what stays internal. |
| MID-059-EX05 | 4 | A 4-person startup with a changing domain and a 40-person bank team with a stable domain: pick a style for each and justify. |
Show solutions
- EX01 Layered: simplicity, but the domain depends on persistence. Hexagonal: domain isolated behind ports, costs extra mapping. Clean: same protection with an explicit use-case ring, costs more ceremony.
- EX02 Invert:
OrderRepositoryandPaymentGateway(outbound ports in the domain); adapters implement them; the service depends only on the ports. - EX03
noClasses().that().resideInAPackage("..domain..").should().dependOnClassesThat().resideInAPackage("org.springframework..")and.check(importedClasses). - EX04 For example
catalog,booking,payments; each exposes anapiinterface plus DTOs/events; entities, repositories, and mappers are package-private. - EX05 Startup: modular monolith with a light hexagonal core (cheap to change, few people). Bank: hexagonal or clean modular monolith with enforced boundaries; justify by team size, complexity, and change rate. Any justified answer using those three drivers is acceptable.
- Outcome 3 is also checked by the lab (ArchUnit and module APIs).
Quiz
Outcomes: O1 compare styles · O2 isolate the domain · O3 modular monolith · O4 choose a style.
A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.
Practical part
Five exercises MID-059-EX01 to EX05 plus the lab. Pass: at least four exercises correct (including EX05 with the three drivers named), ArchUnit tests passing, and the payment adapter swapped without domain changes.
Common mistakes
Interfaces for everything with no boundary meaning; modules that share database tables freely.
Assessment
Architecture-style comparison for a scenario.
Career relevance
Architectural decomposition (SRC-008).