96

Imagine a scenario of two different microservices. One to handle Authentication within the service, the other one takes care of User Management. They both have a concept of a User, and will talk about Users through calls to each other.

Where would the Domain model of a "User" belong though? Would they both have a different representation of what a User is on the level of the database? What about when we have a UserDTO to be used in API calls, would they both have one for their respective API's?

What is the general accepted solution for this kind of architectural issue?

Improve this question

6 Answers 6

Reset to default
52

In a Microservices architecture, each one is absolutely independent of the others and it must hide the details of the internal implementation.

If you share the model you are coupling microservices and lose one of the greatest advantages in which each team can develop its microservice without restrictions and the need of knowing how evolve others microservices. Remember that you can even use different languages in each one, this would be difficult if you start to couple microservices.

If they are too related maybe they are really one like @soru says.

Related questions:

Improve this answer
5
  • 34
    I can't completely agree, If they are completely independent then you have 2 monoliths. The idea is to have smart endpoints and dumb pipes. In enterprise context, you end up (currently my nightmare) hitting the wall because there is an implicit common domain model, (implicit because we didn't foresee it) and each service is reinventing a % of the wheel. And the ecosystem of micro-services is growing with a focus put 100% in functionality and team ownership, messing it up with domain model. We have teams creating new services, consuming others, duplicating much effort. Still unsolved.
    – juanmf
    Jan 21, 2016 at 21:02
  • 5
    We have also left aside a very important Architecture Significant Non Functional Requirement, performance. These services needing other services' output, render a multilevel communication approach for each client RQ. Adding latency that can't be addressed unless a heavy refactor and possibly micro-service merging is made.
    – juanmf
    Jan 21, 2016 at 21:07
  • 4
    Plus, not having a common understanding of the domain model, caused teams to apply unnecessary "unmarshalling + object-object transformations" to adapt micro-services responses to the model that the calling micro-service adopted. I know that coupling all services to a common domain model lib can bring other operational issues, but I find neither option satisfying.
    – juanmf
    Jan 21, 2016 at 21:37
  • 4
    @juanmf It would be very valuable if you could post a question about your issues. I'm also interested in hearing opinions on this matter...
    – Milos Mrdovic
    Apr 24, 2018 at 10:08
  • 1
    I'll try to sit and write something that makes sense
    – juanmf
    Aug 30, 2018 at 23:00
18

If two services are sufficiently intertwined that it would be a pain to implement them without sharing DTOs and other model objects, that's a strong sign you shouldn't have two services.

Certainly the example makes little sense as two services; it's hard to imagine a specification for 'User management' so complicated it would keep a whole team so busy they don't have time to do authentication.

If for some reason they were, then they would communicate using what are basically arbitrary strings, as in OAuth 2.0.

Improve this answer
7

You can think of them as two separate Bounded Contexts (in Domain-Driven Design parlance). They should not share any data between them, aside from an ID used for correlating the Authentication context's "User" with the other context's "User". They can each have their own representation of what a "User" is, and their own domain model, which just the information needed to perform their business responsibility.

Remember that a domain model doesn't try to model a real world "thing," but what that thing is in a particular context (such as Identity/Authorization Management, or Human Resources, etc).

Improve this answer
4

Microservice is not about "share nothing", but "share as little as possible". In most cases "User" is really common entity (just because User is identified by some shared identificator - userId/email/phone). Such kind of entities shared by definition. The User model is out of scope one microservice. So you must have some global schema, where User (just their most common fields) should be placed. In strict case is id only.

Improve this answer
4

This one seems very good micro-service guide: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/, it suggests that micro-services are following a domain-driven design (DDD) and Bounded Context pattern (https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice), which means they should not share data between them. I could not find a recommendation on what you do and you manage you contracts (DTOs or events).

One option is every service to have its own copy of the contract classes, which might seem a good idea, so every service can evolve on its own. Practically it is not that good idea. In most cases, communication between micro-services physically boils down to exchanging JSON messages with REST or message queues. JSON is case sensitive format, which means that "userID" is practically different than "userId" and "UserId", no matter that semantically this is one and the same. I have seen numerous issues just because of that, and syncing one large landscape is really tough.

What I really like is having a separate library (NuGet, Maven, etc.) which holds the data contracts, so they can be easily reused. In the case of a big landscape, it might be split based on domains. It can evolve and will have different versions. In the case of non-breaking changes, micro-services can continue working with old versions, in case of new API versions, then new versions are released and whoever wants will migrate.

I have heard of an approach where you can have a semantic language to define contracts, and this is compiled to particular classes for different programming languages. The idea is data/contract definition comes first.

Improve this answer
3

They both have a concept of a User, and will talk about Users through calls to each other.

I also agree with what @soru said. If one service needs another service's data, than their boundaries are wrong.

A nice solution is what @pnschofield came up with -- treating your services as Bounded context.

Talking about the subject, put shortly: shared domain models kill service autonomy, turning your microservice system into distributed monolith. Which is apparently even worse than a monolith.

So there is still a general question unsolved -- how to define service or context boundaries, so that they thrive in high cohesiveness and loose coupling goodness.

I came up with a solution to treat my contexts as a business-capability. It's a higher-level business-responsibility, business-functionality, contributing to overall business-goal. You can think of them as of steps your organisation needs to walk though in order to obtain business-value.

My typical sequence of steps I take when identifying service boundaries is the following:

  1. Identify higher-level business-capabilities. Usually they are the similar among organisations from the same domain. You can get a feeling of what it looks like checking Porter's value chain model out.
  2. Within each capabilities, delve deeper and identify sub-capabilities.
  3. Note the communication between the capabilities. Look at what an organisation does. Usually, communication is concentrated within capabilities, notifying the rest about the result of its work. So when implementing the technical architecture, your service should communicate via events as well. This has multiple positive consequence. With this approach your services are autonomous and cohesive. They don't need synchronous communication and distributed transactions.

Probably an example of this technique would be of some interest to you. Don't hesitate to let me know what you think about, since I've found this approach really profitable. Sure it can work out for you as well.

Improve this answer

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