Chikahiro Tokoro's opening talk at wroclove.rb 2025. Challenges the common narrative that monoliths are unscalable, slow to deploy, or unmaintainable by citing Shopify (145 billion requests on Black Friday 2023; peak 60M req/min; 30–40 deploys/day), Facebook (new release every 75 min), and the well-known microservices-hell diagram. Traces a decades-long pendulum between monoliths and service-oriented architectures: SOAP/SOA in 1998, Amazon's 2002 move from monolith to services (later exposed as AWS), Rails (2004), Twitter (2006, later migrating to Scala), GitHub (2008), Building Microservices + Kubernetes + Netflix (~2015), and now a 2025 swing back — ThoughtWorks' macro-trends report says 'modular monolith rises again', Amazon Prime Video moved from microservices back to monolith (cutting cost by 90%), and Google Trends shows Rails spiking in 2025. Compares monolith vs microservices on language, CI/deployment, infrastructure, latency, scaling (scale-up vs scale-out), tracing, and boundary clarity; invokes Conway's law and Sam Newman's warning that microservices are a bad choice for startups (Christian/Euro quote: 'startups with more microservices than customers'), plus the essential-complexity cost of retries and circuit breakers. Argues the next decade belongs to the modular monolith (citing Shopify's Packwerk and Sam Newman). Defines the God object as the real anti-pattern: one class knowing too much, tightly coupled, many callbacks, thousands of lines — causing 'change user registration, break payments' and, if you try to move to microservices with a God object, a distributed monolith. Prescribes two-step refactoring: (1) better modeling — understand DRY as 'single authoritative representation of knowledge' (Dave Thomas regrets how DRY was explained and Chikahiro met him in Tokyo), avoid drying up coincidental duplication, use DDD (recommends Matthias Verraes's blog). Walks a customer/invoice/receipt STI example showing how blind DRY produces a document God object and how separating knowledge yields natural modules. (2) Refactor incrementally with clear business merit — never a big-bang. Shares a real case extracting single-sign-on from a user God object into a Rails engine with a separate database. Recommends the Strangler Fig pattern (Martin Fowler), feature flags, and shadow traffic (referencing Simon's earlier talk) plus a Shopify blog post on real-life gradual migrations. Q&A covers displaying heterogeneous documents (use materialized views / Elasticsearch for read concerns, separate from modeling), metrics for measuring refactoring impact (no great answer — maybe time-to-new-feature or bug count), whether inheritance causes God objects (Sandi Metz: delegation > inheritance), educating teammates about modularity (ongoing struggle), and enforcing domain boundaries dynamically in Rails when Packwerk static analysis isn't enough (audience member describes using active-record boundary checks in test env that reject cross-engine writes not going through a public service API).