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

Question

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.

Answer 1

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.

Answer 2

It depends entirely on your business requirements.

It sounds like the reviewer was pointing in the direction of SOA. Separating into isolated physical modules gives some safety, because parts of the system can fail without bringing down everything.

However, separating the application also brings complexity to the product (specially in scenarios where in order to commit a single business transaction, you must communicate with more than one module).

Answer 3

Having worked on a project that (by necessity of client requirements) inherited a second database by way of subsuming another application, I wouldn't advocate this route. It makes the codebase messy, you often end up with the need to either duplicate data between databases or the need for your business logic to access both databases (either directly or via some other mechanism such as web service calls). In the case in question it was neccesary since one database was Oracle and the other SQL Server so merging the two datastores would have been a significant headache, but it's not a route I would choose lightly.

What arguments were put forward by the reviewer who was suggesting the split into multiple projects with separate databases? Even if you want to split the business logic into separate DLLs by functional area, why the need for different databases and DALs? This seems like introducing complexity for complexities sake, unless your codebase is truly mammoth OR the volume of data being stored is causing performance issues within a single DB that could be mitigated by splitting the data into separate DBs. Given the amount of work likely to be involved in this change, it seems like the onus is on this guy to prove why you should do it!

Answer 4

What I tend to do is first define the sub domains, and make sure they are logically divided based on functionality; not too big, not too small. Each sub domain would then become an isolated piece of software, that consists of service layer, application layer, domain layer and infrastructure layer (as I described here).

This also means that each one of them have their own repositories, but not necessarily a separate database. In fact, I mostly want to keep one database, but use different schemas to identify the domain the tables belong to. This way you can keep constraints between the tables (cross schema) and guarantee data consistency.

So I think it makes sense to structure your code in logical modules (and in fact you should), but I would not do this with the database if this is not really needed, because it would make your life more difficult in terms of maintenance and reliability.

Answer 5

It all depends upon your requirement.

If you need to move to separate physical tiers in future, this can in come handy (you can run each project on different machine thus separating each module). However, this will introduce a decrease in overall application performance. The benefits this would yield is that other projects can access these separate projects/tiers independantly.

I am highly skeptical that you would have any gains by separating databases. Are you planning to move each database to a different box in future? If not, then I'd say stick with a single database with different schemas.