Relationships between aggregates

[paulkre]

I have the following two aggregates:

struct User {
    user_id: Uuid,
    identities: HashSet<AggregateId>,
}

struct Identity {
    provider: String,
    remote_id: String,
    user_id: Option<AggregateId>,
}

So, there is essentially a one-to-many relationship between User and Identity. The code to create a new relationship between a User instance and an Identity instance could look something like this:

tokio::join!(
    user_cqrs.execute(&user_id, UserCommand::AddIdentity(identity_id.clone())),
    identity_cqrs.execute(&identity_id, IdentityCommand::UpdateUser(Some(user_id))),
);

It is technically possible that the resulting events of one of the commands fail to be applied or persisted, while the events of the other command are successfully handled. This would result in the application's state being incorrect, as the relationship between the instances would be incomplete. In relational databases, it is common to have the option of grouping multiple mutations into a single transaction. This ensures that the transaction will only be committed if all the mutations are successful. I was wondering if there is a similar concept in CQRS/ES. Or is there maybe a better way to model relationships between aggregates?

[davegarred]

In DDD, an aggregate always has all the information that applies to itself (if it doesn't, you have a bad aggregate design and need to re-work it). Therefore, the out-of-sync problem is never one that exists within the aggregate, but rather something that exists at the view level.

In this situation, you would likely need to correct it by firing a new command at each aggregate.

E.g.,

enum UserEvents {
  ...
  AddIdentity {
    identity: String
  }
}

enum IdentityEvents {
  ...
  UserResolved {
    user_id: String
  }
}

[paulkre]

Thanks for the explanation. In your example, you meant to write UserCommands instead of UserEvents, right?

[davegarred]

That's correct @paulkre , sorry about that. Though each would have a corresponding event.

Note that those events may not have any effect within the aggregate, they could only be useful for downstream queries. This is not uncommon, I've built systems where only a very small subset of the events are important within the aggregate.