Andrzej Krzywda's wroclove.rb 2022 talk arguing that most Rails projects share the same 'typical' domains — pricing, authentication, shipping, inventory, payments, taxes, invoicing, calendar, etc. — and only a small 'pink' core domain is genuinely unique. Krzywda revisits his own 10-year-old advocacy of service objects, lists the debates they cause (naming, call vs execute, return values, grouping, testing, params-driven flow) and calls them a 'gateway drug' to DDD — useful but not enough. He introduces a two-layer split: an application layer containing Rails controllers, service objects, form objects and read models (and things like admin panels, mobile APIs, GraphQL, Shopify web hooks), and a domain layer that lives OUTSIDE the Rails directory (e.g. in an `ecommerce/` folder), has no dependency on Rails or Active Support, and treats each domain as a pure function from commands to events. Domains don't know about each other; business processes — reactive rules mapping events onto commands — coordinate them. Service objects become thin mappers from params to commands (often collapsible into controllers); form objects validate input but must not save; read models subscribe to events (possibly from multiple domains), are persisted (often as Active Record), are decoupled from one another, and pair well with Hotwire for broadcasting. He demos the rails_event_store 'ecommerce' reference repository, the Event Browser (written in Elm), a DSL for read models, and explains GDPR via per-event encryption keys. Argues the approach is more junior-friendly (smaller building blocks, clearer tickets) and more estimation-friendly than fat Rails, and hopes generic domains will eventually ship as open-source gems. Warns against microservices, Rails engines, Trailblazer-then-removed experiments, and reusing service objects across applications. Closes with Q&A on AOP (subsumed by events), GDPR with backups, risks of modularising too early, DDD without event sourcing, reading from read models, unit testing with fakes, and the overhead of DDD vs Rails' 'fast first weeks, slow later' curve.