8

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?

New contributor
Umair is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 1
    A distributed monolith is not really better than a monolith, usually even harder to maintain. It's a term used to describe a failed transition to a microservice architecture. – Milan Velebit Sep 10 at 14:35
  • 1
    Aren't you confused with authentication and user data ? – user1428716 Sep 10 at 14:36
  • I think it would help you to list what user data these services need. To start, what user information does a notification service require? – JimmyJames Sep 10 at 14:45
  • 2
    Assuming you have all the answers will not help you get any. The point of the exercise is to get you to realize you probably don't need user data in every service. A really clean, reusable microservice will not need 'user data'. It needs a destination for the notifications. – JimmyJames Sep 10 at 15:07
  • 2
    @Umair A good way to find out if you can do this or that with microservices is to determine why you need microservices in the first place. Unless you're trying to solve a specific problem in which they are the superior option, using microservices just for the sake of it is usually a terrible idea that will bite you in the butt like a rabid handmade html-regex parser. Just sayin'. – T. Sar Sep 10 at 16:13
2

If you really need the same User object/model/record in most of your microservices, you probably don't need separate microservices at all OR they ought to be object-agnostic as far as their knowledge goes. Thusly, each microservice manages a sub-type of a User model with the data that's needed for its functionality, with a key that's used to distinguish that User. In an ideal world, that way you can perform the necessary mutations and propagate changes throughout the system through a event broker of some sort (assuming you have a event-driven architecture), otherwise, each service would have to be aware of some (or all) other services and what they're meant to do and which types of objects they expect to receive.

Keep in mind that in a true microservice environment, each microservice is expected to have its own data store which is isolated from the rest of the system, backing up my initial statement that you should dump the concept of a User entity completely.

For instance, a SendNotification microservice would only receive an object with a websocket identifier (which is passed throughout services, eventually reaching this one) and the data that's supposed to be returned to the user, and it'd just perhaps verify that the needed fields are there and push the notification to the appropriate channel by the WS identifier. It doesn't have to know which types of objects it handles at all.

Your Answer

Umair is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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