Domain Driven Design and Onion Architecture in Scala
summary
Claims that combining Domain-Driven Design with Onion Architecture yields more readable, maintainable Scala code and proves it with a code-driven case study that models how to fry an egg. Builds an API like prepareEgg(eggStyle): Future[CookedEgg), uses sealed trait ADTs and tiny wrapper types to encode rules, refactors a mutable frying-pan with exceptions into sum types so many edge tests disappear, defines repository traits with in-memory implementations, and wires modules with a thin cake dependency injection pattern so infrastructure can be swapped without breaking the domain.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 3:39What is Domain Driven Design?
- 6:58Ubiquitous Language
- 8:24Case Study Language
- 10:48Case Study: Bounded Contexts
- 13:08Domain Building Blocks
- 14:58Case Study: Domain objects
- 16:19Onion Architecture
- 19:43Decoupling the Domain
- 21:08Case Study: The First Crack
- 23:06Case Study: Second Crack
- 24:55Case Study: Functional Testing
- 26:39Case Study: How would you like your eges?
- 27:52Tiny Types
- 29:38Case Study: Identifying our Cook
- 33:39Case Study Broken Frying Pan
- 35:52Case Study: Fixed Frying Pan
- 37:32Evolving Truth
- 38:27Repositories and stories
- 39:03Case Study: A Carton of Ees
- 39:45Dependency Inversion Principle
related talks
50mShrek, Onions and Architecture
42mStratified design and functional architecture
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
52mEvolving a Pragmatic, Clean Architecture A Craftsman's Guide
45mDomain-Driven Design in Micro Frontends
31mArchitecting Onion Style Without Making Your Eyes Water
51mA Contrarian View of Software Architecture
32mStrategic Domain-Driven Design