Architecture: DDD mastery
This course covers Domain-Driven Design applied to a Rails monolith, using an LMS codebase as the running example. It starts with ubiquitous language and the split between strategic and tactical design. It then covers bounded contexts and context maps, entities, value objects and aggregates, and the difference between domain services and application services. Later lessons show anti-corruption layers, module namespacing with Zeitwerk, a shared database and domain-based routes. The last lesson compares CRUD, service objects, modular monoliths and microservices to help decide when DDD fits.
What you'll learn
- ✓Ubiquitous language, bounded contexts and context maps
- ✓Entities, value objects and aggregates
- ✓Domain services versus application services
- ✓Anti-corruption layers for communication across contexts
- ✓Namespaces, Zeitwerk and a shared database in a Rails monolith
- ✓Choosing between CRUD, service objects, a DDD monolith, a modular monolith and microservices
What is domain-driven design?
You've built Rails apps. You've scaled them. You've designed systems that handle millions of requests. Sooner or later, though, every growing codebase hits the same wall: the code no longer reflects the business.
Read the full lesson free →Curriculum
7 lessonsWhat is domain-driven design?
Introduces DDD as modeling code after the business, with ubiquitous language and strategic versus tactical design.
Bounded contexts & context maps
Explains bounded contexts, the signals that mark their boundaries, and context mapping patterns across the nine LMS contexts.
Entities, value objects & aggregates
Separates entities, value objects built with Data.define, and aggregates whose root enforces invariants for its children.
Domain services & application services
Distinguishes domain services that hold business rules from application services that order the steps of a use case.
Anti-corruption layer & cross-context communication
Shows how query objects and services act as an anti-corruption layer for reads and writes across contexts.
DDD in a Rails monolith
Covers module namespacing, Zeitwerk autoloading rules, a shared database with optional table prefixes, and domain-based routes.
When DDD is overkill (and when it's not enough)
Places DDD on a spectrum from plain CRUD to microservices and lists the signs that call for each stage.