Ever since seeing Eileen Uchitelle's RailsWorld 2024 talk, I've struggled with the feeling that discussions of modularity are hampered by a lack of consensus on basic terms.
I wrote a few articles to help sort out my thoughts. The third one is probably the most applicable. https://rossney.net/articles/good-boundaries-make-good-systems/
I'm not writing as an expert or any kind of authority, but I sure would enjoy being part of a conversation that promotes clarity around this topic. Please boost.
I propose four conventions for implementing autonomous modules:
1. Packs/modules are only for domain logic. No controllers, views, or other UI objects allowed.
2. Only coupling between packs/modules should be examined for dependency control (coupling to the UI is expected behavior).
3. Only data objects should be passed to and from packs/modules.
4. Packs/modules must own their own data.
Do you think these make sense? Do you have different ideas? I would love to hear about them.
I 💜 Eventide, but they have a strong preference for component-based systems. I would love to work on integrating Eventide (or event sourcing in general) with a modularized monolith system.
I think CQRS also works well with this approach because of the clarity provided by the boundary between UI and domain logic.
If everything were in a monolith, then one or more modules could be responsible for building the tables supporting the views. The first difference is that the UI could call command handlers directly (and receive feedback directly, like validation errors).
I could see running "reactors" to support downstream event handling in the same way that conventional Rails apps run worker queues.
This is all just a thought exercise, but that's the high-level overview I see.
Be Kinder Than Necessary
Jacob Atzen