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

  • 1
    I would keep the test logic in the web service and allow the monolith to request the test preview from the web service. It sounds like the web service already handles the "test" domain so you might as well call it the "testing" service or similar and place all logic there. When you say "Web API should behave as REST as possible" that makes no sense to me. The business domain should dictate how the service operates and what form it takes. There is no standard for RESTful web services.
    – Dan Wilson
    Commented Aug 1, 2020 at 14:00
  • @DanWilson - yes, I should have put that in quotes, because it does not make much sense to me either. Also, one of my pro Web API arguments was exactly domain-related: since it deals with the tests (so with the tests domain), any business logic that deals with test entities should be placed there. Please consider developing your comment into an answer. Thanks.
    – Alexei
    Commented Aug 1, 2020 at 14:06
  • see What is the problem with "Pros and Cons"?
    – gnat
    Commented Aug 1, 2020 at 14:08
  • 1
    I have changed the actual question to avoid the "pros and cons" pitfall. Besides this, is there a way to salvage this post or this type of question is simply not on-topic here?
    – Alexei
    Commented Aug 1, 2020 at 15:03
  • 3
    I don't think you've thought enough about how each architecture will meet your specific needs. You do have to evaluate the pros and cons, but you also have to know what they are first. Have a look at Microservices vs Monolith: which architecture is the best choice for your business? Commented Aug 1, 2020 at 17:06

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

  • The internal app (monolith) is written in .NET Framework 4.6 and the Web API in .NET Core 3.1, so I guess a library written with .NET Standard can be used. Thank you.
    – Alexei
    Commented Aug 8, 2020 at 7:50

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