Honest reflections on organizing code at scale
The modular monolith is the right answer for 90% of Rails applications, and yet the industry spent the better part of a decade pretending microservices were the default. We are finally coming back to sanity. A well-structured monolith with clear module boundaries, enforced dependencies, and explicit interfaces gives you most of the benefits of microservices without the operational nightmare of distributed systems.
Packwerk and the modular Rails movement are making this practical. It is the most important architectural shift in the Rails ecosystem right now.
Domain-Driven Design in Rails is powerful but the community makes it harder than it needs to be. The core ideas -- bounded contexts, aggregates, ubiquitous language -- are genuinely valuable. But the implementation advice often involves so much ceremony that teams drown in abstraction before shipping anything. Command buses, event sourcing, CQRS, repository patterns layered on top of ActiveRecord.
The DDD concepts that matter most in Rails are the strategic ones: where do you draw boundaries, what language do you use, how do domains interact. The tactical patterns are optional. Treating them as mandatory is where teams go wrong.
The real architecture decision is almost never which pattern to use. It is what goes where. Where does this business logic live? Which module owns this concept? When two domains need to interact, who calls whom? These questions are boring. They do not have elegant answers. And they matter more than every design pattern combined. Architecture is not about patterns. It is about organization, and organization is messy, contextual, and political.
This is where years of experience become an asset, not a liability. If you have watched codebases grow, you have seen abstractions succeed and fail. You have felt the pain of a god model and the frustration of over-extracted services. That experience is the raw material for good architectural judgment. This module gives it structure.
Conclusion #
Architecture is the domain of integrators. It is fundamentally about how pieces connect, where boundaries go, and how information flows between domains. The inclination to see systems as interconnected wholes is the exact skill architecture demands. If you have been doing architecture informally for years, this module formalizes what you already sense.
Predictions #
-
You will adopt Packwerk or a similar boundary enforcement tool within three months
-
You will resist the urge to over-extract services and instead focus on clear boundaries within the monolith
-
DDD vocabulary will improve your technical communication more than your code structure
-
You will develop a personal heuristic for "when to extract" that is more nuanced than any book's advice
-
This module will be the one where you feel most confident -- because you have been doing architecture informally for years