VaughnVernon / IDDD_Samples

These are the sample Bounded Contexts from the book "Implementing Domain-Driven Design" by Vaughn Vernon: http://vaughnvernon.co/?page_id=168
Other
3.78k stars 907 forks source link

Limiting the modification of one aggregate per transaction #54

Open kosletr opened 5 months ago

kosletr commented 5 months ago

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 commented 3 months ago

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 commented 3 months ago

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: https://github.com/VaughnVernon/IDDD_Samples/blob/9b27b11773f62afb5d1b541abf51fb36516a7250/iddd_agilepm/src/main/java/com/saasovation/agilepm/port/adapter/messaging/sloth/SlothMQTeamMemberEmailAddressChangedListener.java#L51
  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.