Built to last: A domain-driven approach to beautiful systems
summary
Claim: running a context map and renaming/partitioning code reveals real, testable boundaries so incremental refactors produce stable, lasting systems. Live production code shows using ER diagrams (Railroady / rails-erd — once printed six feet long), modulizing into domains, introducing aggregate root facades, service objects, a message bus via whisper with ActiveJob, and optional RabbitMQ (Pwwka/Sneakers). Example numbers: 5,000 promo codes (2,000 invalidated) motivate domain splits. Works when teams agree; needs buy‑in and restraint to avoid overdesign.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 8:10DomainDriven Design
- 16:10Trip Time vs Trip Cost
- 17:47Bounded Contexts
- 19:10Dependencies
- 19:57Context Map
- 20:43Ideal Outcome
- 22:50Aggregate Routes
- 26:08EventDriven Architecture
- 27:39Command Objects
- 30:13Sharing Models
- 32:31What happens next
- 35:15When to stop
related talks
30m15 Years of Rails With Domain Driven Design - Lessons Learnt
44mBuild to Last...
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book
41mUsing Boundary-Driven Development to beat code complexity
44mAll the cool kids...
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
31mDomain Driven Design and Hexagonal Architecture with Rails