-1

I'm using a microservice architecture. when something went in one microservice I want to catch it in another microservice. To say briefly I have synchronization. But there I have one problem, I have a domain model with its own attributes and behavior, I would like to get that data in another microservice. Basically I'm just sending a request from one Microservice to another and I'm pulling some data, but to get this data I need to have the same model in both microservice.

I got two possible choices:

  1. To have two model one for Domain model and another for response a.k.a "DTO". (Disadvantage: If I update something in the domain model I should update it in the DTO model.)
  2. To have a lot of atomic models for specific tasks. (Disadvantage: hard to maintain all of the models)

I'm looking for best practices for this specific decision.

Improve this question
5
  • 1
    how are you communicating between your microservices?
    – asr9
    Jun 16, 2020 at 13:03
  • 2
    The best practice is not sharing any model at all. Just share events, changes, operations. Let each MS stay aware of these things and do with them whatever they need with their respective models. Otherwise, you are not synchronizing, you are replicating
    – Laiv
    Jun 16, 2020 at 13:03
  • I'm using a service bus for communication. I need to get specific data from one microservice to another to finish the process.
    – Replay
    Jun 16, 2020 at 13:06
  • No good news for you. It might interest. You can find more references if you look for Microservices vs ESB.
    – Laiv
    Jun 16, 2020 at 13:09
  • 2
    I'm a little confused by your question, this same problem exists in every architecture, not just microservices. If the contract for something you rely on changes then you need to change also. Are you asking how to deal with/minimize those changes? If so there may be a better way to phrase it is all I'm trying to say.
    – Captain Man
    Jun 23, 2020 at 21:31

1 Answer 1

Reset to default
1

When you look at an individual service visualise it as "this is the only thing in the world". Note down its inputs and outputs. The outputs go via its API's. Its inputs can come from either its API and/or its message bus. Having two services that depend on each others schema's is an anti-pattern and degrades the benefits you're supposed to be leveraging.

If you need data to go between services, use the message bus; but send the data via events. "This happened" with "this data". Each service can interpret that however it wants and do whatever it wants with it.

Improve this answer

Your Answer

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

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