Build to Last...
summary
Claim: a Rails app can avoid a five‑year rewrite by modeling intent, drawing explicit domain boundaries, and testing the boundaries rather than internals. Uses Ruby + Rails, ActiveRecord, and focused test suites: tests are the first client. Practical rules include keeping ActiveRecord calls inside the domain, treat ActiveRecord as a private API, extract permission logic into separate objects, and use integration specs only as sanity or regression checks. The result is smaller, inspectable neighborhoods that evolve without wholesale rewrites.
AI-written summary · about
chapters (27)
- 0:00Welcome
- 1:28Audience poll: Ruby/Rails
- 2:35Legacy Rails problems
- 4:02Pain points in legacy apps
- 5:30Rewrites often unnecessary
- 6:55Maintainable software approach
- 7:38What software really is
- 8:45Structure and Interpretation of Computer Programs
- 10:34Software and intellectual complexity
- 12:00CS significance beyond computers
- 13:04Big ball of mud
- 14:51Technical debt explained
- 20:21True meaning of technical debt
- 21:26Intent and design focus
- 22:30Ruby for domain modeling
- 23:12Anthropomorphizing code
- 24:54Code neighborhood metaphor
- 26:20Domain neighborhoods example
- 28:04Rails app boundaries
- 29:05Permissions as domain
- 31:54Tests as domain client
- 33:20Testing around domain
- 34:45Domain-driven testing
- 35:48Tests by domain boundaries
- 36:52Humans over machines
- 37:37Designing to avoid failure
- 38:20Closing & Q&A
related talks
27mMaintainable Ruby on Rails
37mBuilt to last: A domain-driven approach to beautiful systems
37mHow I Architected My Big Rails App For Success
11mUse Case Driven Development
01h 05mLegacy Rails Q&A
43mThe Clean Architecture: How to Grow From Startup to Enterprise
32mHow I architected my big Rails app for success!
46mRails as a piece of birthday cake