Vertical Database/Application Partitioning RRS feed

  • Question

  • As a result of an internal debate I'm interested in people's thoughts on dividing an application into numerous "mini-applications" that encapsulate related functionality in services or stand alone applications.  The same approch can be realized with a single application and traditional programming approaches.


    For example, in a large warehouse management system, you could split the application into accounts receivable/GL/Payroll/expense etc. Each "mini-app" would have it's own database and service interface.


    There are pro's and con's to the single and multiple approch. What I'm most interested in is the generally accepted best practices for such an architecture, and whether the mini-application approch is considered a good strategy for partitioning.




    • Moved by Max Wang_1983 Tuesday, April 26, 2011 6:08 PM forum consolidation (From:Architecture, Tools, and Process for ISVs)
    Monday, May 7, 2007 10:25 PM

All replies

  • Hi,


    Sounds a lot like you're talking about Service Oriented Architecture (SOA), well kind of.  The approach is at least.


    A good architecture and design would likely have many subsystems defined within it.  If there were requirements to, or an expectation that the subsystems would be consumed by more than one application, then you would design the architecture to take that into account.  Obviously that would mean decoupling or seperating out each domain, or functional area, as made sense to the problem space.


    In terms of writing mini-applications just for the sake of it, that would probably cause more problems than it would help, as you'd then have to consider security across each of these subsystems, as well as all the other security aspects that must be managed in such a situation.  The partitioning of systems in seperate apps would be over-engineering unless there is a good reason or requirement to do so. 

    If on the other hand, your requirements were such that you would need to seperate out into services, or functional areas or components at least, then part of that design would be that you would implement security from the start in that way.


    "Mini-applications" in terms of thinking of how the software is partititoned, is fine in a conceptual way, but actual seperate applications, in seperate application domains would be quite hard to manage, and there are easier and better ways to do this.


    The idea that you have seperate pieces of code (or services) for an application is a good idea in that maintenance can be easier, since a change in one small component in the system only requires a small change in one subsystem or service, instead of the whole application (if it was monolithic)  Obviously this pre-supposes that you do not make breaking changes to the interfaces that require recompiles in the calling systems.


    Another benefit is that you are able to use the subsystem or service in other systems (obviously so long as the service or subsystem supports it)  It means that you develop a loosely coupled architecture, which makes it less brittle, easier to test, easier to deploy, easier to re-use, easier often to refactor.


    I hope this helps, or at least gives you something to google (or yahoo Surprise) )


    Martin Platt.

    Tuesday, February 19, 2008 10:36 PM