Eileen Uchitelle - The Myth of the Modular Monolith - Rails World 2024

The modular monolith approach promises better structure and less coupling, but cannot solve fundamental human and cultural problems in engineering organizations

Architectural issues like tight coupling and lack of boundaries are caused by engineering cultures that prioritize shipping features over code quality and maintenance

Organizational problems (slow onboarding, code ownership battles, siloed teams) stem from misaligned incentives and blame-based cultures rather than technical architecture

True isolation between modules is extremely difficult to achieve in Rails applications - attempting strict boundaries often leads to worse patterns like primitive obsession and code duplication

New developers need proper education and indoctrination in Rails philosophy and conventions, not just technical training

Tools like Packwork can help identify dependencies but cannot teach good design or fix existing technical debt

Leadership needs to actively reward and prioritize maintenance work, technical debt reduction, and quality improvements - not just feature shipping

Start with minimal modularization and focus on functional isolation rather than strict domain boundaries

Evaluate architectural choices based on team needs rather than following trends - what works for one organization may not work for another

Engineering culture improvements and developer education are more important than architectural changes for maintaining healthy Rails applications at scale