Hi,
I’ve implemented a few big RoR apps. I do have some good experience
building large systems in many different languages and platforms but I
don’t consider myself a RoR guru, so I’d like you experts comment on
my thoughts.
I’d like to divide a large system (app) into several functional, high-
level sub-systems. These are higher level than rails Models, and
provide APIs that implement business logic around functional groups.
Examples of these are billing manager, security manager (accounts,
privileges, roles, etc), inventory manager, manufacturing manager, and
such (of course, these are just examples, but you get the point).
These high-level sub-systems may be implemented as servers (think
SOAP / REST / XML-RPC / …), or just plain Ruby classes. Some of
these sub-systems implement integrations with other systems, for
example, a credit card gateway, an accounting system, Fedex, you name
it. Some of the sub-systems may be just proxies to a system
implemented on some other technology.
The user interface (views) would not have access to any of the Models.
They just present and / or grab data that is prepared for them /
pushed back to the controllers as local variables / arrays / hash
tables that don’t reflect an actual Model.
The controllers do not have access to Models either. Instead, they
call methods from the high-level functional sub-system APIs.
The Models implement lower-level business logic related to how to the
information is stored and retrieved from the database, the pertinent
validations, associations, etc. but do not implement high-level
business logic such as “how do I bill Joe for a specific event that
results in the combination of many other parameters and variables that
at the end come from diverse fields on many different tables on the
underlying database structure”.
The high-level sub-systems all share the same database and therefore
same data model and only communicate with each other via their APIs,
and can access all Models directly.
In other words, this would work more or less as a new layer in between
the MVC pattern:
view <-> controller <-> high-level sub-system <-> models <-> database
The idea is to build the app in a more robust / less coupled way where
I can exchange parts of the app by different technologies and other
applications in the future without having to recode a bunch of things.
For example, the security subsystem could one day be replaced by an
AAA server and then the subsystem would be re-implemented to call the
AAA server (to replace its own original implementation), however the
rest of the app would continue to use the same API calls to the
security subsystem and so the change is isolated from the rest of the
app.
The problem with this is, I’d loose many of the RoR goodness, such as
form helpers, easy models validation thrown back to the interface,
etc.
Am I missing some Ruby language construct or RoR framework construct
that would enable me to implement this kind of design on an easier
manner? Should I instead be thinking of many RoR applications somehow
talking to each other?
I really like RoR but I’m starting to find myself on a tough situation
dealing with evolving mid-to-large systems (think 50+ database tables
and 8+ sub-systems). I need to come up with a pattern that would force
me to implement and design code that works and is maintainable on a
long-term vision, however I’m not sure if this is because I don’t know
the 100% of what the language and framework has to offer, or if I am
just using it the wrong way (or both? :-).
Comments?
Thanks,
Seb