I have a service which is composed of various independent small "blocks" of logical code. A block stands for a class which implements an interface "IBlock" which includes an "Execute" function that gets a BlockRequest parameter and returns a BlockResponse parameter. Each logical block usually does the following: Get some data from a DB, Make an API call, Any specific simple logic over the data, Return a normalized response.
The purpose of this service is to serve an external orchestrator (different service) by executing blocks dynamically according to request. The service is unaware of any business flow, and only knows to execute a specific block on demand. Basically the service is some kind of repository of independent logical blocks.
The service receives request messages via queue, runs some logic according to the request (a specific block) and return an answer by publishing a response message to a different queue.
Outside of executing blocks, the service itself is quite lean and holds little logic - mostly validating the request, logging, writing to DB and publishing back a response. However, there are many "logical blocks" and the number will only increase as we keep using this service.
I will eventually have too many logical blocks which will be hard to maintain and every time
a small piece of logic in the form of a new block will be added - Meaning adding another class to the solution -
I will need to test the entire service and deploy all of it again to support the new block or a minor change.
Separating the blocks into different services could help as it would allow us to deploy and maintain each block separately, but eventually this would mean a lot of services which would also be tough to maintain and keep track of - making this a lacking solution.
Is there any middle ground pattern\technology\design that could help me build this service properly?