I am the primary developer on a Rails application that allows customers to manage artist portfolio websites. There are four very different types of behavior that the system entails:
- Admin behavior, which allows logged-in users to manage the content of
their portfolios - Portfolio Display behavior, which renders users’
portfolios to general visitors - Conversion Funnel behavior, which
displays information about the service and entices new users to sign
up - Super Admin behavior, which displays statistics about the other
three behaviors to the service owners
Currently, these four sets of behaviors are broken up into namespaced controllers—but they all share the same models. I am wondering, since the four parts of the system share virtually no behavior, if there would be any benefit to splitting the application up into four separate applications or engines (and extracting any shared behavior into gems.)
As examples, the part of the system that deals with user statistics doesn’t need to “know about” rendering YouTube embeds in portfolios, the part of the system that deals with displaying portfolios doesn’t need to “know about” A/B testing, and the part of the system that deals with signing up new users doesn’t need to “know about” much else besides signing up new users.
Additionally, a specific problem that I’d like to address is that I’d like for an inexperienced team member to be able to contribute a little bit of code to the part of the site that deals with signing up new users. It wouldn’t be the end of the world if a bug or two got pushed to production in that part of the site but it’s extremely important to not allows bugs in production in the part of the system that displays users’ portfolios.
So, in terms of the maintainability and legibility of the codebase, would it make sense to separate these four components into separate applications? To what extent would doing so simply entail pushing complexity into a different layer of the system without eliminating it? Is this type of separation better accomplished by creating more cleanly decoupled classes and modules?
Thanks much!
A semi-isolated engine would achieve your goals of allowing for silo code work and you can easily shares all of the resources, such as stylesheets (which is likely important since you still offer one service).
A mountable engine also achieves your goals, but the sharing is more difficult, since it seems best to serve as isolated.
A service-oriented architecture with a number of functionally-oriented apps delivering APIs to one or more front-end apps may work. It’d be more work upfront, but it could payoff in the long run if you see the total service getting more complex over time.
Fun choices!