On the whole integration databases lead to serious problems because the database becomes a point of coupling between the applications that access it. This is usually a deep coupling that significantly increases the risk involved in changing those applications and making it harder to evolve them.
Martin Fowler on Integration Database
The friction to make changes is going to be amplified with this approach. It would be moving from spaghetti code to spaghetti architecture. You'd be better off modularizing the code into different libraries if sticking to 1 database.
I don't know your situation but generally speaking, rewriting a large application is going to take multiple times longer than probably will be estimated and it will be a bad time for devs and users. Because users depend on so many behaviors of the current system that they don't realize, so they can't tell you. So when they try to switch to the new system they will hate it because it doesn't do all the things they depend on. You can mostly prevent this but you need to have access to user experts. Interview them to find out their actual business workflows, not just the data they save, and not just reworking the legacy code you have. When something doesn't make sense, rather than forging ahead with your best guess (which we devs seem to do without realizing it), go back and ask your experts more questions. You often find you had some assumptions wrong and need to do some redesign. You will be doing this and discovering new requirements all the way to release and beyond. This is basically applying the non-coding parts of DDD. And of course, have users test out their workflows as you complete them so you get feedback early.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Multiple services with 1 database is the Integration Database pattern.
The friction to make changes is going to be amplified with this approach. It would be moving from spaghetti code to spaghetti architecture. You'd be better off modularizing the code into different libraries if sticking to 1 database.
I don't know your situation but generally speaking, rewriting a large application is going to take multiple times longer than probably will be estimated and it will be a bad time for devs and users. Because users depend on so many behaviors of the current system that they don't realize, so they can't tell you. So when they try to switch to the new system they will hate it because it doesn't do all the things they depend on. You can mostly prevent this but you need to have access to user experts. Interview them to find out their actual business workflows, not just the data they save, and not just reworking the legacy code you have. When something doesn't make sense, rather than forging ahead with your best guess (which we devs seem to do without realizing it), go back and ask your experts more questions. You often find you had some assumptions wrong and need to do some redesign. You will be doing this and discovering new requirements all the way to release and beyond. This is basically applying the non-coding parts of DDD. And of course, have users test out their workflows as you complete them so you get feedback early.