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.
Microservices are the current trend, and they would roughly correspond with your third choice. You can spend a lot of time getting sucked into the literature around microservices, but yes, you will definitely contend with some degree of data duplication and possibly performance issues when compositing multiple microservices into a usable product.
Ultimately there isn’t a right or wrong answer. Take the microservice literature with a grain of salt. They aren’t always a good choice.
1
Build a data layer that matches your DB in a shared assembly. You can the have each of the business layers reference it (the data layer could be all interfaces to keep implementation separate). Then build out each of your use cases in the relevant business layers. You’ll likely have a fourth business assembly which contains objects which implement shared use cases.
6
Schemas are a middle road between different databases and the drawbacks of having different databases. You can have your Customer and your Sales schemas, keeping them totally independeent or mixed as needed.
That gives you (2) without the major headaches with different databases: joins are in database, setup is easy (no linked servers), the data is all kept together (depending on size and usage this may be either positive or negative).