We are designing a new microservice architecture based on an existing huge monolitic application.
We read a lot of informations about how to design microservice and how they can communicate but I can t find any information about this "problem" :
Let say that we have two microservices correctly bounded managing "Building" and another one managing "Person" ;
But, now we also have another microservice also bounded for managing "ReferenceData" (like country, state, ...) and another one for managing "user preference".
How can we manage that a person is "containing" a country (for the nationality) and a building also containing a country (for the address of it) ?
When a user is calling one of the business microservice (Person or Building) can we do a simple sync HTTP call to retrieve the user preference ? may we seen it as an anti-pattern ?
Can we put a definition of those "shared stuff" (c# class) on a shared assembly (.net) ? or is there any other best practice that need to be take into account ?
Thanks,
The whole point of microservices is that they are independent. You can create a service that has countries (for example so that you can display a list of available countries), but I would avoid binding that service to your other ones. Copy the country information into those other services. This allows these services to evolve independently. For example, if a person has nationalities that are at a finer grain model than buildings country (because subtleties like that really happen in the real world).
Services can call other services, coarser business services should caller finer-grained ones, but do not make a network, make sure that you strongly define your hierarchy, and make high-level services call low-level ones. I don't think "Building" or "Person" services are those coarse-grained services, you probably want a layer above them that is integrating those with preferences. Building and Person probably should be on their own, but Microservices design is not an exact science, and a lot depends on your situation. If User Preferences is deeply integrated into the behavior of Person, it might make sense to make Person your coarse-grained service. Just make sure that it's an explicit decision, and you don't do something horrible like make them co-dependent on each other.
Finally, do not create a "Shared Stuff" assembly. It will become your Monolith in very short order, and will bind everything together into an unruly mess. You will end up with all the disadvantages of a monolith, combined with all the overhead of microservices.