JAMES-3142 Rely on event sourcing to correct current group registration #3303
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
test this please |
1 similar comment
|
test this please |
…oups The unbinding subscriber need to retrieve the actually performed bindings in order to enforce the binded groups to be the required groups. This means that groups will also be eventually unregistered upon errors.
…oups The unbinding subscriber need to retrieve the actually performed bindings in order to enforce the binded groups to be the required groups. This means that groups will also be eventually unregistered upon errors.
By moving the registered group detection to the emitter, and maintaining the diff between registered and required groups throughout the aggregate we are able to achieve retries of failed unbind without emmitting events on the happy scenario (required groups = registered group & no change), limiting history growth.
chibenwa
force-pushed
the
event-sourcing-2
branch
from
c095e21
to
398eeaa
Compare
mbaechler
reviewed
Apr 17, 2020
| this.eventStore); | ||
| } | ||
|
|
||
| public Mono<Void> start(ImmutableSet<Group> requiredGroups) { |
There was a problem hiding this comment.
you need your aggregate to build your command, that looks like a design violation.
|
|
||
| import com.google.common.collect.ImmutableSet; | ||
|
|
||
| public class RegisteredGroupListenerChangeEvent implements Event { |
There was a problem hiding this comment.
You are not describing events (like groupAdded or groupRemoved) but a state, it's not event sourcing anymore.
|
Thanks for these design considerations |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up of discussions happening here #3280
Vocabulary:
required groups: the groups that the event bus uses, and that should be eventually registered.
registered groups: the groups actually registered within rabbitMQ (the queue exists and is bound to the main exchange)
The goal of GroupUnregistringManager is to make the required groups converge with the registered groups.
From the required groups, the GroupUnregistringManager loads the registered groups, and manages the vision of required/registered groups via the aggregate. A subscriber actually binds/unbinds as needed the exchange to make the two ensembles converge.
Keeping track of required and registered groups within the same aggregate is handy from an auditing purpose.
Also, it allows firering an event only when needed (updating the history or fixing a divergence).