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).