Background:

I work on a small group (5-10) of lightly used .Net web applications.

The applications typically have dedicated databases, but there are instances of an application accessing another application's database directly. There is also a common database that most of the applications use a source of truth for some data

I have been trying to decide on a methodology that we can begin to adopt to prevent the following types of questions:

• How will a proposed change to the database affect our family of applications?
• Which applications use this table?
• How did our database connections become a hot spaghetti mess?

Possible Solutions:

Here are the possible solutions I have thought of:

• Accept the current position and allow applications to access each other's databases as needed
• Follow a 1 database <--> 1 application model and have the applications communicate via API when they need to get information from each other
• Create dedicated code libraries / packages for database access, which are consumed by our applications
• Move toward a mono-repo solution where multiple applications share a single repo. Build modules within that repo to be responsible for database access
• Investigate using a message bus of some kind.
  • I do not have much experience in this area and it seems like overkill to me.

QuestionsQuestion:

My goal with this question is to have a full list of reasonable approaches I could take, so I can consider the pros and cons and pick an approach.

Can anyone think of other possible solutions that I am not considering?

Has anyone else encountered a similar situation? If so, what solution did you choose and how did it go?