Spring Cleaning
summary
Shows how to structure a Spring Boot service so business logic lives in pure Java domain packages, use cases become first‑class objects, and the domain owns the ports/interfaces while adapters implement them as separate modules. Uses Java 17 records, JUnit/Mockito tests and Spring only for wiring, achieving 100% test coverage for the domain with sub‑second test runs. Enforces dependency direction via ArchUnit rules and packages adapters as a Maven multi‑module set so individual adapter jars can be built and released independently.
AI-written summary · about
chapters (20)
- 0:00Intro
- 2:04My Current Context
- 2:49Culture is What You Do
- 4:05The Big Ball of Mud
- 7:47Architecture includes...
- 14:27What makes code "good"?
- 17:41What makes an architecture "good"?
- 20:42What use cases do we need?
- 21:30First steps...
- 21:47Make Payment Use Case Analysis
- 26:03Make Payment Algorithm
- 31:00Get the domain under test
- 36:34Finishing the domain
- 41:43Integrate with SpringBoot
- 43:08Decide how to implement ports
- 45:57The Resulting (Clean) Architecture
- 48:12Clean Architecture Rules
- 49:35What are the tradeoffs?
- 52:24Maintaining the Architecture
- 54:34Testability
related talks
38mEmbracing Clean Architecture in Spring Boot and Kotlin
50mSpring Modulith – Spring for the Architecturally Curious Developer
49mMagical Beans and Mystery
52mSpring Recipes: A Collection of Common-Sense Solutions
33mSpring for Architects
02h 47mSpring Patterns for Grown-Ups
01h 01mImplementing DDD Patterns with Spring
56mSpring For Architects