Needed help to refactor my code
suppose i'm following controller->service->repo structure, what if service of one domain calls the repo of another domain, can we do this? for examle there is a repo that basically deals with gold prices fetching the latest gold price from the dB, and it has it's own service layer and then i have another class called as Payment Service that deals with creating payment request so in order to get the latest gold price can my payment service call gold repo, or i should create an entry inside the payment repo that basically calls the goldPrice repo and then gives the data to payment service class. Needed help on this.
There should be a logical boundary across services. Anything related to Gold (price fetching, update etc.) Should sit in 1 single service and any other service would call that API/method.
Yes that's correct, but as of now GoldPrice is an independent service that basically deals with getting the latest gold price and all other stuff, but I have created another service called as Payment Service that needs the latest Gold price from Gold Service so that's what I wanted to confirm can I directly call my GoldPrice repo from Payment service?
Would not be a good practice to directly call gold repo from payment service. In future if there's any new service which requires gold price, would you also make direct calls to gold repo from that service as well? And let's say if there's any change in logic of fetching gold price in future, you would have to update it across all the services which are fetching gold price from repo. That would create a consistency and manageability problem.
Why not have a Gold service which calls your gold repo and payment service (or any other service that requires gold price), make calls to that Service layer. Any logical changes in gold price fetch, update would need to be done in only 1 gold service and all other services are just it's consumers.
If you go through SOLID principals, separation of concern is of utmost importance.
So it’s not recommended to call other repos from one service. Instead, what you can do is create a master service (I.e. service layer over services) and use both gold service and payment service inside it.
Then you would question why to complicate code soo much?
We want to achieve loose coupling by doing this. So if tomorrow you want to change your DB or the logic to fetch the data it can be easily done without changing the core logic of calculating price
Yeah that seems like a good approach, but as an alternative to this can my Payment Controller call the GoldPrice service and hence I can remove cross service or cross service-repo dependency?
Yes your controller can call the gold service to fetch the price but make sure that remaining logic should be processed by some other service and it should not be in the controller
See more comments
You can maintain a separate repository responsible for handling API calls and external dependencies. This way, your Payment Service can depend on this dedicated repository for fetching the latest gold prices without directly coupling to the Gold Repo. This enhances modularity and keeps concerns separated, promoting a cleaner architecture.
We follow this in our project which was similar to yours example .
Yeah ig that could also be a solution because my Graph Service also requires latest price
Discover More
Curated from across
