> "There are so many books, blog posts, and frameworks out there that will tell you to add more layers to your cake (project). There are very few that will tell you to cut your cake." > — Robert Pankowecki, *Domain-Driven Rails* ## The Insight Rails projects grow by adding **horizontal layers**: MVC → service objects → form objects → serializers → repositories. This is the default advice. But layers don't reduce complexity — they just contain it more neatly. The DDD move is different: **cut vertically into bounded contexts** — subsystems that own their own models, data, and logic. - Horizontal layers: more rows in the same cake - Bounded contexts: separate slices of the cake ## What a Bounded Context Is A bounded context is a subsystem with: - Its own **ubiquitous language** (words mean specific things inside this context) - Its own **data ownership** (tables it writes to) - An **explicit interface** to the rest of the system The same word means different things in different contexts. `Product` in a Sales context has `name`, `description`, `quantity_ordered`. `Product` in a Pricing context has `unit_price`, `promotional_price`. `Product` in an Inventory context has `SKU`, `QOH`, `location_code`. These are three different classes — not one big one. ## Why This Matters in Rails Rails encourages one `Product` class that holds all three. Every context just reaches in via associations. This works at small scale. At scale it means: - You can't change the `products` table without knowing who reads it - You can't refactor `Order` without tracing the full association graph - Every developer needs to understand the whole app to change any part Bounded contexts keep cognitive load local. You operate inside a context; crossing its boundary should require a deliberate decision. ## Related - [[50-Column Class as Multi-Context Signal]] - [[Three Heuristics for Splitting ActiveRecord Models]] - [[Domain Events as Cross-Context Interface]] - [[Bezos API Mandate]] — organizational parallel: Bezos mandated the same principle at the service level