Where should I place more complex business logic related to what a Web API does but consumed by a single client?

Question

I have been debating with my colleagues about the following and we still did not reach consensus.

The architecture is as follows:

• medium size monolith application for intranet usage

• a small application that features a SPA and a Web API which allows some folks to fill in some tests (Internet)

• both applications use the same database and our team handles both

• the flow is the following: someone initializes a test in the internal app and it becomes available in the external app, the external app deals with issuing the test and computing the score which becomes available for the internal app.

Now, the request is to allow the internal app user to preview the test. This comes the debate related to where to place the business logic: in the monolith vs. in the Web API.

Arguments for the monolith

• knows best what to display and that is why it should request lists of DTOs (sections, questions, possible answers etc.), aggregate and sort + display the data
• Web API should behave as "REST as possible" for external clients and only provide simple endpoints (e.g. get a list of entities and children in this case).

Arguments for the Web API

• Web API already handles the test display, so it already has the data models and business logic to display them to the user. Aggregation, sorting and caching is already performed there and can be almost entirely reused to construct monolith specific required DTOs. Shortly put, the tests domain is in the Web API, so any business logic using those entities should be placed there unless there is a strong argument to do otherwise

• stop developing in a monolith and develop in a lightweight service instead

• avoid duplicating almost the same business logic in two places

I am interested in what is the recommended way to proceed in such a case.

Question: Where should I place more complex business logic related to what a Web API does but consumed by a single client?

Extra details required through comments

There is no migration towards microservices and the moonlight will not be rewritten any time soon. However, some functionality such as the described Web API must be separate since it will be deployed differently (e.g. DMZ as opposed to the Intranet for the monolith).

Answer 1

I think this boils down to the following situation:

• there are two applications A and B

• both need a common functionality / complex business logic for which duplication is not desirable

• one wants to decide if the common functionality is better placed in A or B (but none of these two places is "naturally" better suited)

In this specific case, if the logic is placed in B (the Web API), it might be easier reused than from A (the monolith) than the other way round, so B seems to be the easier option, as suggested in some of the comments.

However, in general, one may consider another approach: create a library or service C for the common functionality and reuse it from both places, A and B.

The question did not state what programming languages / eco system is used currently, and if the monolith and the Web API can use shared libraries. If yes, a common library may be enough, if not, C needs to be implemented as a service as well. But I hope the general idea becomes clear: by moving the common functionality to a third place,

• duplication is avoided

• none of the existing applications gets too many responsibilities (so the Web API itself stays lightweight, for example)

Note this does not require the monolith to be changed into a microservice architecture, though the creation of C as a service might be seen as a step into that direction.