This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U78ETENHDU8
As we evaluate modularlizing our Rails monolith, our first step was to pull the entire “backend” (services, models, & related) out into an engine and clean up the dependencies with the controllers. Now that is done, we are starting to evaluate how to decompose the “big ball of mud” engine. Initial ideas are to either pull functionality “down” (finding contexts that don’t depend on the BBoM and extracting them) or pulling contexts “up” (identifying contexts that are directly called by the controllers and not by other services and extracting them). Pulling contexts “down” seems easier, but pulling contexts “up” seems to have greater logical impact.
Does anybody that has been through this have an experience with trying either or both of these approaches and would like to talk about what went well/poorly?
I would say, don’t sweat the direction question too much. More core models tend to only wanna move down. Models more on the side tend to move up more easily. Ultimately, you can also think of all these moves as steps towards more/better separation. As such, what you are doing with these steps is learning about boundaries. Or said another way: its all good and it all makes you better.
The initial split did seem to make the most sense to us. Ultimately we’ll be breaking up the “front-end” into engines as well, but we’re pretty sure that the relationship between front-end and back-end engines will not be direct 1:1 mappings, so this way we start with complete freedom breaking up the back-end and then will pull apart the front-end as we identify that we can isolate the dependencies of a particular UI area.
I would agree with that and to add a bit further: extracting parts of the back-end in such a way starts to remove the mapping from frontend to database making the UI changes much easier