Project Architecture, transferring data between core and services

Question

I'm sorry for my english. There was a large java project(spring, hibernatne and etc) having the monolite architecture. Let's name it a core. Adding a new features was hard work so it was accepted a decision to make new features out of the core and then link them over http(REST api). Now there are the core and many "services" around it, but the core and services have one DB. Services don't transmit any data to each other. They work as a demon or the core makes request to them. When the core calls any of services, the following happens: a service gets request, makes directly sql query to the DB, executes own logic over received data and returns result to the core. I think it's a bad practice to use the common DB so i'd like to close directfull access for any of service to DB.

I have 2 idea how i can do that:

1. for modification, i'd like to use events(Create, Update, Delete) and a boker(ActiveMQ, RabbitMQ)

2. for reading, i have one of 3 options:

   2.1. to make internal API for each select query on the core side(it isn't a good option because we don't want to recompile the core that often)

   2.2. to let services directly read data from DB

   2.3. to pack sql query into some object on the "service" side and send it to the core, over there query will be unpacked and executed and result will be sent as a array of JSON back to client. Also on the core side i will check that it's only "select" query.

I'd like to ask you some question:

1. is it a good option to separate reading and modification like this?
2. which of options for reading could you recommend me?
3. if i choose 2.3 option for reading, what a framework could you recommend me? i have started to look at JOOQ, but it may not fit for that at all

thanks

Answer 1

The right way of doing this would be to have the services work in isolation with each having it's own databases and queues, but you could also use an external provider, which could be your current database.

Using the events to make data changes in the source database would be wrong, because events are actions that already happened. Events act like triggers, and even though you can persist the data they carry, you should only do it to have data redundancy across your services, i.e.: the shipping services needs to know a client address so it keeps it's own copy of that address even though the address is stored in the clients service.

Now back to your questions:

1. You can separate readings and writings but not in the way you're describing
2. Option 2.2 is the more correct one.
3. For reading, use JDBC or some lean orm like Dapper