Domain Driven Design and Hexagonal Architecture with Rails
summary
Claims that Domain‑Driven Design plus a hexagonal layout stops Rails’ fat‑model drift and makes code reusable across web and API boundaries. Actual techniques shown: form object (ActiveModel::Model) for complex forms, request object (using Verdis) for validated API boundaries, service objects and a repository + mapper layer that converts ActiveRecord rows into ~8 domain classes (down from a single 48‑attribute AR model). Repository wiring, scope proxy and an identity map are implemented; repository work proves the hardest but the pattern works and a GitHub repo is promised.
AI-written summary · about
chapters (30)
- 0:00Intro
- 1:32Declans story
- 3:42Steve Martin
- 4:47More than Rails
- 5:40Rails Folder Structure
- 6:07Areas of Responsibility
- 6:35A Train Wreck
- 7:57Patterns
- 8:39Domain Concepts
- 9:27Eric Evans
- 10:12Understanding the domain
- 10:54Ubiquiti language
- 14:26Hexagonal Architecture
- 14:38Application Level Code
- 15:20Form Object
- 17:41Request Object
- 18:23virtus
- 19:13validation
- 20:16service objects
- 20:44order service
- 21:25Active record
- 21:58Architecture
- 22:34Repository
- 22:53Save
- 23:53Scope
- 24:41Mapper
- 26:03Identity Map
- 27:07Service Directory
- 28:01Embrace Complexity
- 29:46Github
related talks
46mHexagonal Architecture with Ruby
37mBuilt to last: A domain-driven approach to beautiful systems
30m15 Years of Rails With Domain Driven Design - Lessons Learnt
46mRails as a piece of birthday cake
28mIf It Bleeds, It Leads
38mRails hurts, because you're using it wrong. Let's fix that
37mPatters to deal with big ActiveRecord models
35mRails vs. Object Oriented Design