Search code examples
architecturedata-access-layerbll

Is it better to divide a software into multiple modules with each module having its own database

I am working on a health care application mainly developed in asp.net with Oracle 11g as backend. In its current state the application is divided into 3 layers i-e UI, BLL and DAL. Since the BLL and DAL are class library projects they are deployed as single dll (one dll for BLL and other for DAL). Recently the software was reviewed an another developer who came up with the suggestion to divide whole software into separate modules each having its own projects and database i-e inventory module as InventoryUI (asp.net Web Application project, InventoryBLL (Class Library project) and InventoryDAL(Class Library project). All modules getting three different projects with separate database communicating with each other through web services.

So my questions are

  1. Is this suggested architecture better than what we have?
  2. Is it better to have more than one dll for BLL and DAL. What are the pros and cons.
  3. Is it better to have more than one databases for single application? How?

Any links, suggestion are more than welcome.

Solution

  • The advantages to physically separating your modules is that it permits the work to be logically broken up amongst different teams. In your case you could have an Inventory team who is responsible for all things inventory related, they publish an API, and to all other teams the inventory module's underpinnings are a black box. This is an advantage to tackling complexity in your domain.

    The disadvantage is if your project is small you may introduce a lot more complexity in the software development and deployment process, especially if you do something like go across process (or machine) barriers.

    1. The suggested architecture may be better based on the needs of the project especially in regards to size. Some compromise may be a better approach as well - if you find that you may have dozens or a hundred modules grouping similar modules together is a practical approach.

    2. More than one DLL for business logic and data access is fine, as long as there is a common ancestor that provides base classes to draw upon. Each DAL having its own configuration in regards to connection strings is a very bad place to be in. Likewise if one DAL uses a mapper pattern and another uses active record - while both patterns can coexist - these patterns should be provided in base classes.

    3. Assuming your RDBMS supports multiple schemas I would first use multiple schemas before going to multiple databases. I go to multiple databases when the nature of the database changes - high transaction volume vs. high read volume (analytics). If you have transactions that need to go across modules and you've physically separated your databases managing these transactions may become unnecessarily complex.