microservices: How to model related domain objects? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this 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

I've looked at the nano services anti-pattern and indeed in my opinion option (a) is an example of it.

But also, you need to consider that your domain logic here, dictates the "Project-Contracts" coupling(it's by definition) therefore the finest(smallest) granularity of the microservice should include the whole thing(Project-Contracts coupling).

Suggestion: I'd go for option (b) with the following twist, but only if you think that handling the Contracts alone requires too much code: consider having it as a private service class (not exposed to the outside world) that should only be constructed by a parameterised constructor which takes the ProjectID(or similar) as its parameter.