Build Complex Domains in Rails
summary
A concrete Rails recipe: an iOS App Store MVP is modeled with aggregates (App as entry point), value objects as immutable POROs for screenshots and versions, and cross-aggregate work in plain Ruby domain services. Uses ActiveRecord scopes, JSON serialization, and ActiveRecord’s read_only! plus manual writer methods to persist value objects. Claims: this reduces business-rule defects and scales past the brittle stage where apps hit 50 to 100 models. Example code shows methods like submit_release and scope-driven queries that make the domain simpler and maintainable.
AI-written summary · about
chapters (16)
- 0:00Brought to you by
- 2:07WHAT'S A DOMAIN?
- 2:39WHY DDD?
- 3:52AIM OF THIS TALK
- 8:37COMMUNICATION
- 9:08RESPONSIBILITIES
- 9:28UBIQUITOUS LANGUAGE
- 10:59App Store relationships
- 13:51Submit a new release of an app
- 15:15AGGREGATE
- 16:32Data Access
- 18:19One expressive point of entry
- 22:50What's what?
- 25:15A. Inline on the Entity's table
- 26:55C. In its own table
- 28:47Gift an App
related talks
41mAPPLICATION ARCHITECTURE: BOUNDARIES, OBJECT ROLES, & PATTERNS
31mWhat Comes After MVC
37mBuilt to last: A domain-driven approach to beautiful systems
46mRails as a piece of birthday cake
44mBuild to Last...
43mThe Clean Architecture: How to Grow From Startup to Enterprise
44mReal-World Functional Ruby
39mFunctional Architecture for the Practical Rubyist