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.
That's a big topic. Eventide uses one or more Rails apps for the UI. They build tables to support views by monitoring event streams and feed form data back into the event streams to initiate commands.
Commands (and downstream events) are handled by anywhere from dozens to hundreds of components that are all independently deployable. They all write the results of their activities to event streams.
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.
One hurdle is that Eventide is written around the convention of Useful Objects and uses a bespoke testing framework. Both are cool, but it creates some friction to integrating with libraries that don't use this style.
Should you mate Eventide with Hanami or Rails and maybe rewrite or wrap the highest level components to avoid this friction? Or should someone make a Hanami-like framework in the Eventide style? 🤔
@dcrossney Why is integration with web frameworks a problem? I understand how eventual consistency makes some classic UI patterns impossible. But beyond that I don’t see much of an issue.
At least I’m imagining that constructing a database with a view of the data should not be that difficult. And putting a webapp on top of that sounds straightforward to me as well.
Well, problem is maybe not the right word. But it would be odd to mix Eventide and, say, Hanami framework objects in the same codebase. They are written in different styles, with important differences. There is also some overlap in functionality, parameter parsing and validation for example. I think it would add to the cognitive overhead of the project.
Be Kinder Than Necessary
Jacob Atzen