CODEWITHSUNDEEP
restoopdomain-driven-designmicroservices
DmitriBodiu
DmitriBodiu

Reputation: 1210

Adding Data from UI to different microservices

Imagine you have a user registration form, where you fill in the form: First Name, Last Name, Age, Address, Prefered way of communication: Sms, Email (radiobuttons).
You have 2 microservices:

When user is registered we should create 2 aggregates in 2 services: User in UserManagementContext and UserCommunicationSettings in Communication.
There are three ways I could think of achieving this:

  1. Perform 2 different requests from UI. What if one of them fails?
  2. Put all that data in User and then raise integration event with all that data, catch it in CommunicationContext. Fat events, integration events shouldn't contain domain data, just the ids of aggreagates.
  3. Put the message in the queue, so both contexts would have the adapters to take the needed info.

What is the best option to split this data and save the information?

Upvotes: 1

Views: 577

Answers (2)

Vishal Shukla
Vishal Shukla

Reputation: 2998

As you mentioned to store communication settings, assuming that communication data are supposedly not part of the bounded context of UserManagement Service.

I see a couple of problems with approach #3 proposed in other answer. Though I think approach #3 in original answer is quite similar to my answer.

  • What if more communication modes are added? Naturally, it should only cause Communication Service to change, not UserManagement Service. SRP. Communication settings MS should store all communication settings related data in its own datastore.

  • What if user updates his communication settings preference only? Why user management service should take burden of handling that? Communication settings change should just trigger changes in its corresponding micro-service that is Communication Service in our case.

  • I just find it better to use some natural keys to identify & correlate entities across micro-services rather than internal IDs generated by DB. Consider that tomorrow you decide to use completely different strategy to create "ids" of user for UserManagement service e.g. non-numeric IDs, different id generation algorithm etc. I would want to keep other micro-services unaffected of any such decisions.

Proposed approach:

  • Include API Gateway in architecture. Frontend always talks to API Gateway.
  • API Gateway sends commands to message queue like RegisterUser to be consumed by interested micro-services.
  • If you wish to keep architecture simple, you may go with publishing a single message with all data that can be consumed by any interested micro-services. If you strictly want individual micro-services to see only its relevant data, create a message queue per unique data structure expected by consuming services.

API Gateway in microservices architecture to perform writes

Upvotes: 1

Alex Buyny
Alex Buyny

Reputation: 3185

Perform 2 different requests from UI. What if one of them fails?

I don't think this would do. You are going to end up in inconsistent state.

I'm for approach 3#:

  1. User is persisted (created) in your user store.
  2. UserRegistered event is sent around, containing the ID of the user.
  3. All interested parties handle UserRegistered event.

I'd opt for slim events, because your services may need different user data and its better to let them to get this data on their own rather than putting all the things into the event.

Upvotes: 4

Related Questions