I'm new to microservices, and from my understanding, DDD says for microservices to be built around business domains. This means good microservices would be like AppointmentScheduler and SendNotification in the context of a meeting booking system.
In this example, both of these microservices will require access to user data to fulfil their business functions, and I'm struggling with the best way to provide it.
To me, a User seems like an object that should exist as an entity inside a microservice, but it would need to exist in most microservices as user data is required almost everywhere. This also introduces a lot of duplication.
The other option is to have a User microservice that provides CRUD operations on the user database. This can then be used by other microservices to access the user data, but the problem I have with it is it tightly couples services together to the point where we end up with a distributed monolith, that is slightly better than a monolith in itself.
Does my reasoning seem valid? How are others dealing with problem?