Microservices: how to model related domain objects?

Question

I have 2 domain objects: project and contract. A project can have many contracts, so in the database it is modeled as a classic one-to-many relationship. Our question is: how do you model above in the context of microservices? Do you (a) have 2 microservices ProjectService and ContractService? or (b) Do you have one ProjectService that includes both projects and contracts?

We think that the answer (a) (i.e. 2 microservices ProjectService and ContractService) implies that it would be necessary to call 2 services to retrieve and save the full hierarchy of project objects. On the other hand, the answer (a) completely separates the Projects from the Contracts, which can be useful in theory, but practically useless, since the Contract cannot logically exist without the Project.

What is the right approach? Is answer (a) an example of a nano service anti-pattern?

Answer 1

It depends on how complex the “design” and “contract” domains are. By answering the following questions, I hope you can make the right decision:

• Isolating the perspective of change: Do you expect changes in the requirements of one domain to be independent or more frequent, and then to another?
• The prospect of team customization: Do you expect these features to be implemented by individual / multiple teams? Will they be able to work independently of each other without any knowledge of the domain of the other team?
• Technological Perspective: Do You Expect Design and Contract Domains to be More Effective with Different Technologies?
• The prospect of data consistency: can you accept the possible consistency between the project and the contract?
• Non-functional requirements: are the performance and availability requirements for these services different?
• Technological risk perspective: Do you already have a distributed system and the necessary experience within the team?
• The prospect of cohesion: try to simulate services, is one of them completely independent at runtime from the other? Mutual dependencies are a sign of high cohesion and poor candidates for various services.
• Customer service perspective: will these services have different customers? Will both of them be available by other services?

If the answer is yes to almost the whole question, then go to 2 microservices. I think that is most likely not the case.