We have a microservices application and our User management service is the source of truth for user's first and last name. But we also need these in the Reporting service, where we generate reports for the users that should contain their first/last name. Our Billing service also needs these names when sending claims to external providers.
One possible solution that comes to mind is to emit UserCreated/Modified events from the user management service and replicate the names in the billing and reporting service. That would work but as I was made aware, the services should own their data and should not need external data from other services. So would you handle that? Maybe we should rethink our service boundaries but on the other side – how would you name a context that manages users and also bills and also generates reports?
Best Answer
Two or more services can hold and manage "copies" (or partial copies) of data coming from other domains (services) and there are good reasons for it. For example
Source and ownership are not responsibilities necessarily exclusive to a single service. Data is data and belongs to the system (as a whole).
What's exclusive to a service is the authority, the knowledge required to operate with the data. What makes User service valuable is not the data, it's the knowledge. Information and knowledge are not the same thing. A proof of it is that, you can get data from a queue or broker, making these the source of trust, but the only who can tell if the data is valid or not, is the service.
Maybe.
Microservices can be formed of smaller services, or two domains to be so correlated that worth unifying both into a single one to ease development and management. Nevertheless, this is not the case for Users, Billing and Reports. Their respective business differs considerably from one another.
I would analyze the context for which I'm duplicating the data.
By duplicating data into another boundary, we give a new context to this data. The data's lifecycle and the needs for availability or consistency might have changed, the previous rules and policies might not be applicable to new context. E.g. committed invoices are immutable; no change is allowed; no change coming from the User Service should be propagated to committed invoices. In this new context, the user's data is expected to be treated differently than in User Service, because, in essence, they are different data (despite representing the same thing), so the Billing Service will rule the user's data associated with invoices according to the billing service rules, not the user service rules.