0

DDD: Can aggregates get other aggregates as parameters? According to this, its OK to use aggregates inside another aggregates. But its requires to change multiple aggregates at one transaction. So is it truth that this rule can be easily skipped and I can change multiple aggregates at one time (especially in case of Microservice). The only problem that I need to lock whole aggregates? Thx

I have a simple situation: User, Friendship and Friendship request entities. User can be aggregate root. DDD and Homogeneous Many-to-Many Relationship

But I would not like to use eventual consistency (especially inside on micro service) cause anyways when I handle that event (FriendshipRequestSent) I need to lock another dependant aggregate. And need to handle and write event on error.

yytrofimov
  • 15
  • 6
  • "But I would not like to use eventual consistency" You can have consistency only internally to one aggregate. The only way to be consistent across **entities** is having them inside the same aggregate, so for you would mean having an aggregate consisting of all the Users :) – rascio Dec 01 '22 at 19:36
  • @rascio, Why not? I have one DB inside that micro service so its easy to load two aggregates at once, lock them and do some stuff? – yytrofimov Dec 02 '22 at 09:11

1 Answers1

0

So is it truth that this rule can be easily skipped and I can change multiple aggregates at one time (especially in case of Microservice).

Yes, maybe.

The only problem that I need to lock whole aggregates?

No - there is the additional problem that, because you are modifying multiple aggregates (or more precisely, domain entities that belong to multiple aggregates) in the same transaction, you also need to be careful to design your persistent storage so that updates to all of the entities can be committed in the same "transaction".

That is simple enough when, for example, the entities are all stored in a single relational database, and you can use general purpose operations in the relational database to control your writes.

But if you are working with a different kind of data storage, where you cannot easily control the writes to all entities at the same time, then it gets a bit spooky.

In an "ideal" world, we could pretend that all information is local, and storing it is just an implementation detail. In practice, the actual implementations we get to use only approximate this idea, and we have to be mindful of the differences.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
  • Thank you very much! In my case there are User aggregate (and for example related SteamAccount), Friendship aggregate (that accepts user_id and friend_id to link with another aggregate=User), FriendshipRequest aggregate accepts user_id and friend_id as well. The only reason I wouldn't like to user Friendship and FriendshipRequest like entities inside User aggregate that I don't want to load all these data when I need to change username or profile pic. So I use domain service to send_friendship_request. And inside that micro service I use one Postgres. Thx for answer – yytrofimov Dec 03 '22 at 14:18