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

  • 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 yesterday
  • @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 yesterday
  • 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 yesterday
  • 2
    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? – Robert Harvey yesterday

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.