In our monolith application, the piece of code that used to handle sending SMSes and emails was written in our business layer. Now the responsibility of sending emails and SMSes is handled by a microservice. Lets call it SendMicroservice. Now other microservices call SendMicroservice if they want to send any emails and SMSes. Lets say this microservice is named WantsToSendMicroservice.

Now typically, the norm in our organisation is to have a service layer for talking to the outside world. The business layer for taking decisions and data access layer for talking with databases, just a typical N-layer architecture.

Now in which layer of WantsToSendMicroservice, should it talk to SendMicroservice? Currently in our organisation, it is done in business layer. But there they just talk to the SendMicroservice. Typically no decisions are made there. Is the business layer an ideal place for microservices to talk to each other or that should be done in some other layer? Maybe the service layer or some other one?

  • Ideally, MS don't care about other services, so I would consider other MS (even those within your domain) to be "external systems". There's nothing wrong on having business (domain) services requesting infrastructure services to send a message somewhere. The business might decide "when to send" a message and leave the infrastructure service to decide "how" to send it. that's a healthy way to implement these architectures. Decoupling.
    – Laiv
    Oct 8, 2018 at 7:35

2 Answers 2


Ideally talking to outside resource (micro-service) should be part of infra layer. These are services that typically talk to external resources and are not part of the primary problem domain. It will be easy in future if we want to replace the existing infra (in your case SendMicroservice), can be done easily without modifying business layer. For reference: https://www.bennadel.com/blog/2385-application-services-vs-infrastructure-services-vs-domain-services.htm

  • In the blog you cited, they mention a Gateway, which is another place that you can talk to outside resources (micro services). Oct 6, 2018 at 17:41

From what I gather, SendMicroservice is internal and has already abstracted the dependencies used to generate SMSes or emails. There isn't much reason to further isolate it in the client service. I would keep it in the business layer because it did make a decision: the one to send a notification for a particular action. I don't know if you have decided on communication methods but if possible avoid a synchronous one which can fail. A queue would work well here. Even if SendMicroservice is called synchronously, its endpoint should just receive and validate and store the item to be processed from a queue to decouple failures/retries.

  • Your reasoning seems logically correct. And as you mentioned the call to SendMicroservice is done asynchronously via message broker. I will upvote your answer. But since this question is very subjective, lets wait to see if anyone else also responds to this. Is it ok ?
    – kumarmo2
    Oct 10, 2018 at 5:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.