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:

Software architecture as is


  • 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:

Proposed architecture

  • 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:

The final architectural proposal

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?

  • For the counterarguments, is there a reason that the external SPA wouldn't do API calls to the internal API instead of having two separate APIs? Just thinking in my head, the API on the internal side could have multiple lines of business (internal and external in your case). Commented Jul 25, 2020 at 22:40
  • @epharham7861 External app can call internal app API.
    – Alexei
    Commented Jul 26, 2020 at 3:40
  • I don't see a good reason to have seperate API's. If the back office employee is meant to have more privileges than the external client then what you really need is a security model that enforces role privileges. Commented Jul 26, 2020 at 7:53
  • @candied_orange One of the main reasons behind having a separate external API was to work in .NET Core 3.x instead of .NET Framework. There is currently a very narrow set of permissions for the connection string user of the external application. However, I am more interested in where to place the business logic clearly related the external API taking into account that the team want to work more using the .NET Core rather than .NET framework.
    – Alexei
    Commented Jul 26, 2020 at 9:46

1 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: basicDiagram

  • Your proposed solution makes sense and makes things simpler, but I am wondering if moving external API to the internal network will be possible (requires some approvals since SPA will make calls within the internal network).
    – Alexei
    Commented Jul 27, 2020 at 5:09
  • 1
    Yeah, that was why I asked if that external SPA could call an API on the internal network in my previous comment. Something else to keep in mind, while you have the ability to use API keys and a security model to ensure privileges are enforced, you also have the option of specifying Route Prefixes and Routes. This would allow the internal and external apps to specify explicit access to routes for a specific route prefix or individually specified routes. Just a little more separation to handle validation of privileges. Commented Jul 27, 2020 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.