CODEWITHSUNDEEP
microservicesdomain-driven-design
eren arslan
eren arslan

Reputation: 207

DDD data duplication for microservices

I have User, Payment, Product, Checkout services. User means for payment; payer , Product; seller, Checkout: buyer etc. When new user registered. I publish event which contains user. And Store user data for all services. That means 15000 user is X4 = 60.000 user data for all services.

Is that Ok ?

Or what should I do ?

Upvotes: 3

Views: 1869

Answers (2)

jlvaquero
jlvaquero

Reputation: 8785

I agree with afh answer.

A different model of a domain concept (User in this case) in every Bounded Context (BC) is the way to go. In the User BC you have the model just needed to manage the Users and its info NOT related to any other BC. In other BC you have the buying data of the buyer, the selling data of the seller and a reference ID to the User BC. Now, for optimization and isolation reasons, you could find that you need to duplicate some User BC data in Payment BC to avoid a query to another BC to accomplish some operation; then duplication it is ok.

This is a golden rule in DDD and/or Microservices. Do not try to reuse your source code models in serveral BCs (at least by default). This also aplies to the DDD roles. A domain concept (User) could be act as a Aggregate in a BC, as a Entity in other BC and as a VO in another one; so you need 3 different models in 3 different BCs.

Also remember that your views are not Domain operations. If you have to show (just show; if you need the data for rules and invariants of the BC process then this data belongs to the process BC; wich could lead to a possible data duplication) User BC data in a payment BC process you are allowed to query both BC or query a denormalized ReadModel you builded for performance purposes, etc

Upvotes: 1

Andreas Hütter
Andreas Hütter

Reputation: 3911

Is that Ok ?

The duplication of required data itself is totally okay from my point-of-view in a Microservices architecture if it happens for the right reasons. And I even would not necessarily consider this as a normal data duplication in the first place.

Each Microservice has it's own domain model and thus the User model - which you already name differently in the different services (payer, seller, etc.) - represents something different in the different contexts. There is very likely also data added to those user objects in each service that are not even known to the user service.

Or what should I do ?

... but you should still reflect on the representation of the user data in each of your services. It might not even be necessary to build a projection of the user model (seller, buyer, etc.) in each of your services as soon as the user was created.

I would only do that if I needed to have some user information at hand already inside, for instance, the product service when I have to perform some domain logic. There is a good chance you only require the id (or let's say unique username) of the corresponding user in one of your services to connect a user to some domain entity. Or you could even create the corresponding user object on demand, e.g. during a checkout process.

Upvotes: 4

Related Questions