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?

closed as primarily opinion-based by Scant Roger, user53019, Ixrec Dec 3 '15 at 7:53

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    OK, why the down vote? Is this question not useful? Does it not show research effort? What is the problem? – chrisl08 Dec 1 '15 at 9:34
  • 1
    It's a great question. One I had as well. A big shame, the SE Programmers closed it. I guess they're trying to make it a weaker brother of SO... :( – Pepster Sep 11 '16 at 13:50
  • Why was it closed? This is a very practical question. – java_mouse Dec 1 '17 at 4:01

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.