none
Modulewise Product Architecture RRS feed

  • Question

  • Hi all,

       Here i am with an architecture related question / discussion. We have developed a generalized product for different industries(Eg: Assembly, Discrete etc). Its the time to move next version of the product.

       Here we are thinking to module wise separation so that each type industry package only have the modules related to that industry. (The existing product includes all the modules and set visibility false to module which are not applicable to the industry.)

     

      The following are suggestions and the ideas came from the team about updation.

      1. Different Database for each module so that we can include only that db in that particular industry installer package like that.

      2. One database but each module table have separate coding standard (for table names) and control with this coding standard

      I need your suggestions among this. What are the effects of separating schema or database? Is this good method ?

      My ultimate goal is that each industry type have different installer package. The package includes core module and their industry based module.

      Also some particular company needs customization so this custom modules are also included in that company .

    Can anyone explain the best architecture for this type of generalized product?

     

     

    Wednesday, May 4, 2011 2:30 PM

Answers

  • Separating out the databases is a bad idea if there is any interdependence at all.  It's a real nuisance having to link across two databases and make sure any restore matches exactly.

    You're best sticking with one database.

    I would go further and recommend you install all the tables etc for everyone so long as this is a server or full desktop you're installing on.  If it's a phone or whatever that's very short of space then it might be worth selectively installing tables.  Otherwise it's simpler if you just have everything there.  Simple is good.

    Customisation is a bit of a nuisance for databases.  Depends on how much customisation you're talking.  Having hundreds of different versions of source code with one unique per client is a really bad idea.  In that case you need a mechanism that can cope with whatever the customisation is  without or with minimal code changes.  OTOH that's an overhead so if there are occasional small changes for just a few clients then partial classes or selective compile can be attractive.

    The common approach nowadays is not to install a main database on the client at all and instead for the software house itself to host the data and use web services.  With cheaper and more reliable hosting of web servers and database servers it's not unusual for the data to be out on some virtual machine.

    This approach has a number of benefits some of which are flexibility, charging, obviating piracy and maintenance.

    • Marked as answer by akhilrajau Wednesday, June 22, 2011 6:23 AM
    Thursday, May 5, 2011 10:31 AM
  • Explanations for your questions

    1.This necessiates the existance of master table or system tables which holds the information about the modules, the tables etc.

    ---- As there would be diffrent modules and different tables (for these modules), there needs a table wherein the information like what  modules are installed, which are the tables (and other objects like views, SP's, constraints) pertaining to particular module. Probably this would drive the menu options in the application as the menus invoking the modules, would need to be visible. Such master table would also help to detect any DB objects which are not installed through module installer or specified process because in such scenario en entry(into the master table) for such module would be missing from master table.

    2. The different naming convention for DB might help but for code base, unified coding/naming convention would be preferable.
    -- The different naming convention for table like say you have ACCOUNT, BILLING modules. Then the tables in these modules can be name as ACC_MASTER, BILL_MASTER etc but for code the distinction can be made by namespaces itself and I hope there won't be repeatabilty of classess across the modules.

    Hope this helps.


    Thanks
    • Marked as answer by akhilrajau Wednesday, June 22, 2011 6:23 AM
    Friday, May 6, 2011 10:46 AM
  • Irrespective of modular product or other applications, layer pattern (an architectural pattern) is an important artifact to be employed. This faciliatates the sepration of concerns e.g. data access would be taken care by some component, business logic would be taken care off by other and also promotes resusability, consistency and changability. The cost of change would be minimal whan you have diferent layers. In some case,performance needs an attention in case of layer pattern but for complex products, it pays off.

    One can even think of runtime generation of queries for mudular product which whould be independent of module and their table design and such component can be shared across all modules.

    Hope it helps.


    Thanks
    • Proposed as answer by Vishvvas Monday, May 9, 2011 5:44 AM
    Monday, May 9, 2011 5:44 AM

All replies

  • Find comments as follows

    Approach 1: In this way, there would be spearete DB for each module which would incur additional overhead for multiple connections to different DB's, posing issues when table from different Db's needs to participate in queries and for reporting, analysis etc, versioning of these DB's, administrative tasks like backing/restoring up of such DB's, and may be few worries for logging,perfomance etc. Also one need to keep information of these DB's in a master DB or master table in main DB.

    Approach2. This apparoach is being followed in few established product oraganizations. This way one can have installer for different modules with installing DB objects (tables etc) in one DB for multiple products. This necessiates the existance of master table or system tables which holds the information about the modules, the tables etc. This helps better in customization incidents as the customization would happen in the same DB eliminating the issues with different DB's. The different naming convention for DB might help but for code base, unified coding/naming convention would be preferable.

    In all, approach 2 is recommended.

    Customizability always provides profitability but also offers few challnges for maintenance and support as the customer is always going to have different Db than the development environment. This can be taken care by keeping all such DB schemas at release facility.

    Hope this helps.

     

    Thursday, May 5, 2011 8:43 AM
  • Separating out the databases is a bad idea if there is any interdependence at all.  It's a real nuisance having to link across two databases and make sure any restore matches exactly.

    You're best sticking with one database.

    I would go further and recommend you install all the tables etc for everyone so long as this is a server or full desktop you're installing on.  If it's a phone or whatever that's very short of space then it might be worth selectively installing tables.  Otherwise it's simpler if you just have everything there.  Simple is good.

    Customisation is a bit of a nuisance for databases.  Depends on how much customisation you're talking.  Having hundreds of different versions of source code with one unique per client is a really bad idea.  In that case you need a mechanism that can cope with whatever the customisation is  without or with minimal code changes.  OTOH that's an overhead so if there are occasional small changes for just a few clients then partial classes or selective compile can be attractive.

    The common approach nowadays is not to install a main database on the client at all and instead for the software house itself to host the data and use web services.  With cheaper and more reliable hosting of web servers and database servers it's not unusual for the data to be out on some virtual machine.

    This approach has a number of benefits some of which are flexibility, charging, obviating piracy and maintenance.

    • Marked as answer by akhilrajau Wednesday, June 22, 2011 6:23 AM
    Thursday, May 5, 2011 10:31 AM
  • Thanks both for your suggestions.

    Hi Vishvvas,

      Can you please explain the following sentences from your reply

    1.This necessiates the existance of master table or system tables which holds the information about the modules, the tables etc.

    2. The different naming convention for DB might help but for code base, unified coding/naming convention would be preferable.

    Hi Andy ONeill,

      So you are telling that installation of database is though web service. If i am wrong Can you please explain me the concepts you told?

     

    Thursday, May 5, 2011 3:21 PM
  • Nope.

    The database isn't installed at the client at all, it's somewhere else.

    The data is exposed by a web service.

    Thursday, May 5, 2011 3:33 PM
  • k so database installed in  a general server and the data is access though web service. This is nice way but this is a product which includes web application, windows application and windows service. So database must be in client place' server.

    We are thinking that, if the database install module wise, client can only see their tables only. We don't need to show unwanted module related tables there. This is one of the main reason to go for module wise separation. I think you got my scenario




    Thursday, May 5, 2011 3:43 PM
  • Well they'd only see the extra tables if they go looking in the database.

    It's quite common for software suppliers to insist customers don't go messing with their database.

    A number of suppliers deliberately name all the tables with meaningless names and refuse to provide a schema explaining how the data is held.

     

    Friday, May 6, 2011 8:09 AM
  • Explanations for your questions

    1.This necessiates the existance of master table or system tables which holds the information about the modules, the tables etc.

    ---- As there would be diffrent modules and different tables (for these modules), there needs a table wherein the information like what  modules are installed, which are the tables (and other objects like views, SP's, constraints) pertaining to particular module. Probably this would drive the menu options in the application as the menus invoking the modules, would need to be visible. Such master table would also help to detect any DB objects which are not installed through module installer or specified process because in such scenario en entry(into the master table) for such module would be missing from master table.

    2. The different naming convention for DB might help but for code base, unified coding/naming convention would be preferable.
    -- The different naming convention for table like say you have ACCOUNT, BILLING modules. Then the tables in these modules can be name as ACC_MASTER, BILL_MASTER etc but for code the distinction can be made by namespaces itself and I hope there won't be repeatabilty of classess across the modules.

    Hope this helps.


    Thanks
    • Marked as answer by akhilrajau Wednesday, June 22, 2011 6:23 AM
    Friday, May 6, 2011 10:46 AM
  • Thanks friends.. In the code wise thinking to create general single class file for data layer operations. Now this is page wise only. So each page operations are different class file. 

    Which method is advisable?

    Friday, May 6, 2011 2:05 PM
  • You mean like a viewmodel?
    Friday, May 6, 2011 5:56 PM
  • We are thinking to separate the layers. So db operations are in one class and use these class in all modules.This is one method.

    Another is each module have their own class for db operation.

    Which one is advisable in products..


    • Edited by akhilrajau Monday, May 9, 2011 6:30 AM
    Sunday, May 8, 2011 2:14 AM
  • Irrespective of modular product or other applications, layer pattern (an architectural pattern) is an important artifact to be employed. This faciliatates the sepration of concerns e.g. data access would be taken care by some component, business logic would be taken care off by other and also promotes resusability, consistency and changability. The cost of change would be minimal whan you have diferent layers. In some case,performance needs an attention in case of layer pattern but for complex products, it pays off.

    One can even think of runtime generation of queries for mudular product which whould be independent of module and their table design and such component can be shared across all modules.

    Hope it helps.


    Thanks
    • Proposed as answer by Vishvvas Monday, May 9, 2011 5:44 AM
    Monday, May 9, 2011 5:44 AM
  • The latter could describe entity framework.

    I'd recommend EF4.

    Monday, May 9, 2011 8:21 AM