Where to place the business logic for an external application that is tightly coupled with an internal application and how to adapt the architecture?

Question

I and a colleague had a rather strange discussion with our boss related to the architecture of the applications we are currently developing. The C4 (second level) diagram of the existing architecture is the following:

Highlights:

• shared database between the external app and the internal one
• the internal one is developed in .NET Framework (development team wants to develop less of that)
• the external one is developed using .NET Core (development team wants to develop more of that)
• the internal application is using a database first approach (development team wants to develop less of that)
• the internal application is using a database first approach, to be changed to code first

I have initiated a discussion about slightly changing this architecture due to various issues:

• security (connections made by DMZ app inside the internal database)
• developments related to External App are often done in the internal one because "we have all the relevant data there anyway"
• the shared database makes deployments harder and riskier (the external application has a few tables among hundreds of internal application tables)

My proposed architecture is the following:

• external application has its database (more secure)
• any development that relies mostly on external application business entities should be done within the External API
• the internal app can get data via API calls from the external API

We have received the following counterarguments for our proposal:

• since the external App is basically a module of the internal app, using a shared database is more convenient. This makes it OK to have external app business logic (consumed by the internal one) coded within the internal one codebase.
• if we want to have external app related business logic elsewhere, we should have a separate internal API

In this case, the architecture would be something like this:

This proposal seems strange to us because it requires an extra application (another pipeline, more complex deployment) instead of relying on the existing API. It makes me wonder what is the proper place to put the business logic related to the external API business entities?

Question: Where to place the business logic for an external application (module) that is tightly coupled with an internal application and how to adapt the architecture?

Answer 1

Making two APIs, in this case, is probably causing a bit of confusion as far as where business logic should live. For me, I would avoid having two APIs, if possible.

If there is some company specific SOP or customer requirement to have separate APIs, then I would use the internal network API to have all of the base/core business logic, and the external network API as implementations of internal API requests. Maintenance might become an issue, since you would need matching classes in both APIs. You would probably run into the possibility groups of things that do not have the same reasons for changing more often.

It would be more beneficial to take the existing API on the external network and move it to the internal network. This would give you the option of having all, or almost all, business logic in one component instead of chained together through multiple components. It could be almost all, since there might be some business logic that is UI/App specific.

As far as adapting the architecture, outside of moving the API from external to internal, the external SPA, the now internal API, and internal app would need API keys defined. the key would be/have some identifier to determine if the requesting app is internal or external. In the API, you can use the key to determine if a request is valid for the calling app.

Here is just an oversimplified concept: