Limiting the modification of one aggregate per transaction

[kosletr]

Hello! I really enjoyed the book and the papers. I have a question. As you also mentioned in the Effective Aggregate Design Part I: Modeling a Single Aggregate paper, a rule of thumb says that we should be limiting the modification of one aggregate per transaction. I am wondering why though? How does this rule of thumb help us? Why not persist two aggregates in the database under the same transaction? Thanks!

[kosletr]

For example n com.saasovation.agilepm.application.team.TeamApplicationService.java the method changeTeamMemberEmailAddress modifies two aggregates, the ProductOwner and the TeamMember under the same transaction. Isn't this a violation of the rule of thumb?

[VaughnVernon]

For example n com.saasovation.agilepm.application.team.TeamApplicationService.java the method changeTeamMemberEmailAddress modifies two aggregates, the ProductOwner and the TeamMember under the same transaction. Isn't this a violation of the rule of thumb?

Two reasons:

1. There will be either the ProductOwner or a TeamMember updated, never both in the same transaction. The incoming event message from the Identity and Access Context doesn't contain a role name, just the user's email address. I decided to query both even though only one will be found, in order to simplify the single application service method. See:

   IDDD_Samples/iddd_agilepm/src/main/java/com/saasovation/agilepm/port/adapter/messaging/sloth/SlothMQTeamMemberEmailAddressChangedListener.java

   Line 51 in 9b27b11

   this.teamApplicationService().changeTeamMemberEmailAddress(

2. Email addresses are never changed in the Agile PM Context, only in the Identity and Access Context. Even if there were to be a single user playing both the ProductOwner and TeamMember roles, there would never be a collision. (I don't recall if there is a business rule to prevent one user playing multiple team roles.)

HTH.