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:
- 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.
- Within each capabilities, delve deeper and identify sub-capabilities.
- 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.