DEV Community

Discussion on: Everything You Need to Know to Get Started with Microservices

Collapse
 
shulugh profile image
Sesugh Hulugh

I have read a number of articles on microservices and this has been by far the most simply explained. Would like to have an idea of what domain model designs would be like in this scenario. Eg I have a microservice that manages warehouses and inventory, then another that manages purchasing of goods that will be stored in these warehouses, will I have to replicate the domain model and database table for warehouses in both applications? Because if the purchasing microservice pulls its warehouse list form an API coming from the warehouse service, then purchasing can never happen if the warehouse microservice has an issue

Collapse
 
saramiteva profile image
Sara Miteva

This is a topic that is discussed a lot with many different opinions involved.

In general, sharing a database between microservices is not a best practice because you can quickly lose control over who is doing what with the database. Database update of one microservice could potentially corrupt other microservice and you will end up with a broken system.

Another thing to consider is that microservices should do more than CRUD operations, otherwise you should consider merging multiple services that solve one domain problem in one. So if you need
data for inventory I guess there would be additional logic that you wouldn’t like to duplicate in the purchasing microservice.

When applying domain-driven development, the domain is the holy grail. You group system functionalities based on domain problems they are solving. Reliable communication between microservices is something that should be solved with different strategies like a circuit breaker, events, queues, error handling, etc.