CODEWITHSUNDEEP
aggregatedomain-driven-designmicroservicesevent-drivenbounded-contexts
Matster2
Matster2

Reputation: 147

Sharing Aggregates Between Microservices

I posted a question earlier about how notifications, and users seeing those notifications, could be modelled in DDD.

Link Here: Does everything have to be an aggregate? Many-to-Many Link

For a brief summary of this:

We can raise notifications in the system that we want to show users. (A notification will target certain users, which you define a filter for. E.g. only show admins, only show normal users, only show users for x client) When a user sees a notification we want to mark it so they don't see it again.

A suggestion was made on the post to have a notification aggregate and store the reference to it in the User aggregate. So when a notification is created, the event will be picked up, and a service will add that notification to the users it seems fit.

So we have a notification list in the user.

I think this is a bounded context (a notification bounded context). Certainly if i was modelling it as a microservice, I would handle this notifications stuff in its own microservice.

If we were to use microservices, the user created event would come from another service (a users service).

Question: The notification creation would go in the notifications microservice. I would also be tempted to put the user marking that they have seen a notification in that service as well.

So at this point, the notifications microservice wouldn't hold a full aggregate of a user, it would only have a partial, containing the; id, collection of notifications and any criteria might want to filter from

Is it ok to have an aggregate (be it a partial one, as it is only the stuff we want) in a microservice (notification microservice) that it isn't owned by? So essentially we have an aggregate of the user in the users microservice and the notifications one.

This doesn't sound too bad as it is going to reduce the footprint on the user, by splitting parts up and it is nice to bundle this functionality into the service that handles it.

However do we want to keep all the user stuff in one place? even it it puts other functionality in with it? Would the seeing of a notification go in the user microservice (that feels wrong)

Thanks

Upvotes: 0

Views: 522

Answers (1)

Kit
Kit

Reputation: 21729

In short, don't share the aggregates, share projections of those aggregates, which are value objects representing aggregates from other bounded contexts.

Is it ok to have an aggregate (be it a partial one, as it is only the stuff we want) in a microservice (notification microservice) that it isn't owned by?

What you call a "partial aggregate" I would call a projection of an aggregate owned by a separate BC. So this projection can be owned by the BC exposed in the importing microservice. In this sense, yes, it is ok.

So essentially we have an aggregate of the user in the users microservice and the notifications one.

No, you don't. You have User in its BC and you have a projection of the User in the Notifications BC. A BC can own the projections of aggregates from other BCs but not the foreign aggregates themselves. You only want to project what you need from the other BCs, not everything. If it was everything, then you've pretty much broken some fundamental DDD. And from a physical perspective, you might be tempted to share databases and so on, which defeats some of the hallmarks of good microservice architecture.

Question: The notification creation would go in the notifications microservice. I would also be tempted to put the user marking that they have seen a notification in that service as well.

I think this would be OK. It sounds like it from the context of your question (I certainly don't know the whole of what you're doing). Perhaps in your Notifications BC, you have a NotifiedUser with a list of Notifications or perhaps it's the other way around SeenNotifications with a list of Users.

Upvotes: 2

Related Questions