Good day. I will try to describe the task: there was a big project on JAVA, over time the project grew even more and it was getting harder to make changes to the monolithic application. Then it was decided to take part of the functionality to the “services” with which the kernel will communicate via REST, but at the same time, the services executing the adopted logic directly addressed the kernel database for writing and reading data. That is, these are not services, but simply a part of the business of logic outside the monolithic core. Over time, the idea emerged to make the so-called services more independent and to begin by blocking the possibility of direct access to the data.

Data access was divided into 2 categories:

  1. modification (it was decided to do through events and message buses (broker))

  2. Read data. And here the question arose how best to do it. While 3 options come to mind:

    2.1. leave the possibility for services to read data directly from the database

    2.2. do internal api methods on the kernel side (I don’t want to, since you don’t need to touch the kernel once)

    2.3. wrap the sql query built in the service into some object, send it to the http kernel with a query, already in the kernel check that it is select, execute and return the answer back to the service in the form of a json array. And the service already has it parked into a normal list of objects with which it will work.

Unfortunately, the project is very large and there is no possibility to rewrite it, the task is to improve its architecture and interaction of the kernel with the services “services” with as little blood as possible.

I would like to know the opinion of experts on the issues:

  1. Is this a normal scheme in this case (separation of reading and writing)?
  2. which of the options to read prefer?
  3. if you still use the option of sending a packaged sql query and executing it with the kernel, which framework would you advise? I now drew attention to the JOOQ I do not know whether it is suitable for this or not?

Thanks in advance.

It is closed due to the fact that it is necessary to reformulate the question so that it is possible to give an objectively correct answer by the participants aleksandr barakin , enzo, user194374 , sercxjo , Streletz July 8, 16 at 16:40 .

The question gives rise to endless debates and discussions based not on knowledge, but on opinions. To get an answer, rephrase your question so that it can be given an unambiguously correct answer, or delete the question altogether. If the question can be reformulated according to the rules set out in the certificate , edit it .

    1 answer 1

    1. It seems to me that separating reading from writing is a very good idea. Reading and writing have different specifics. To read you need to extract a lot of things, and even pull up a lot of extra. When writing, a smaller amount of data is modified, possibly one or two lines from one or two tables. When recording, logic is added. When working in a team, this separation is very convenient: 2 non-overlapping tasks, at least from the point of view of the Application Services Layer . One complex task is divided into two simpler. It is even possible to use different mechanisms for working with DB. In our C # -com project for reading is NHibernate (an analogue of Java Hibernate ), and for writing - Dapper , roughly speaking, SQL - scripts.

    2. I think that:

      • 2.1. (leave the opportunity to services to read data from the database) - not promising. It is good to have a layer of services that return JSON , then according to the principles of SOLID it will be possible to reuse these services for clients made on different technologies.
      • 2.3. (send SQL -query) is also somehow not beautiful, because the database to some extent remains not isolated, which will complicate the future development of the system when adding security requirements or authorization. My experience is not enough, but this option does not seem beautiful. Perhaps there are other reasons why.
      • 2.2. (to do the methods of internal api) - the most suitable with my tz, because it is possible to easily expand the functional. Although I am not sure (I don’t know the real case). In order not to change services every time, you can not have api as services with many methods, but a lot of Query . Each Query is a set of parameters for performing a single read operation. Each Query has a QueryHandler that executes it. Query can be put into a separate assembly, so that both the client and the server are used, and only make changes in this assembly. I know how to implement this approach with Query in C # (approximately, partially - 3 response points by reference) , but in Java , taking into account the specifics of WebApi , I don’t know.

    3. I do not know.

    In the end, you can come to CQRS .