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 this: How do you model the above in the context of microservices? Do you (a) have 2 microservices ProjectService and ContractService? or (b) Do you have one ProjectService which encompasses both Projects and Contracts?

We are thinking that answer (a) (i.e. 2 microservices ProjectService and ContractService) implies that one would have to call 2 services to retrieve and save the complete Project object hierarchy. On the other hand, answer (a) completely decouples Projects from Contracts which may be a good thing in theory, but practically useless since a Contract cannot logically exist without a Project.

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

Answer 1

It depends how complex "project" and "contract" domains are. By answering the following questions I hope you will be able to make a right decision:

1. Isolation of changes perspective: do you expect changes in requirements of one domain to be independent or more frequent then in another?
2. Team setup perspective: do you expect those functionality to be implemented by separate/multiple teams? Will they be able to work independently without any knowledge about the domain of another team?
3. Technology perspective: do you expect to project and contract domains to be implemented more effectively with different technologies?
4. Data consistency perspective: can you accept eventual consistency between project and contract?
5. Non-functional requirements perspective: are performance and availability requirements for those services different?
6. Technological risk perspective: do you already have distributed system and necessary expertise inside the team?
7. Cohesion perspective: try to model the services, is one of them fully independent in runtime from another? Mutual dependencies are a sign of high cohesion and bad candidates for different services
8. Service clients perspective: will those service have different clients? will both of them be accessed by another services?

If answer is "yes" to almost all the question then go ahead with 2 microservices. I think that most likely it is not.