I am currently working to replace a bunch of legacy applications. The first one is getting close to being released, which will mean I will be starting the second one.
Each application deals with a specific part of a sales process. Initial customer acquisition (with potentially very little customer data, with a lot of it being optional intentionally), through to actual quote/sale process, and then on to an application looking at how to get customers back into the beginning of the sales acquisition process.
Now I have built applications for many years, used different techniques, all with their pro's/con's, without really knowing the preferred way.
- One large database, re-used by all of the applications to share customer data etc. This can make it a lot of work to maintain, having loads of developers all working on the same schema and services, having a dependency to most likely have to release all applications at the same time following changes
- Database split per area (Customer, Sales, Business Hierarchy etc), gives a logical split, but they are all still used by all of the applications, yet joins for data across databases can cause problems unless you do cross-database joins/link servers etc
- Each individual application has it's own set of databases. This makes development of each application a lot quicker and simpler. Yet also gives a lot of duplication in data copying it across each application. Then any changes in data needs synced somehow with other databases. For some areas you could open up a web API to get to some data between them, but a lot of the time you may end up having to read from one database to use that info to get more info from another etc rather than doing simple quick joins.
Can anyone give some info on the correct way? Yes, things can possibly be subjective, but I'm sure one of these ways would be more recommended than the other.