Subscribe to Events from another aggregate instance

Imported from Google Groups
1

Hello Everyone,

i have a question if i am missing a concept regarding the subscription of events of a specific aggregate instance.

my situation is as follows:

I have a User (Aggregate) that can be associated with one or more Issues (each is another aggregate). Now when something happens in a specific user (resulting in an event), i want the associated Issues to subscribe to this event (but only of that User Aggregate Instance). Is there a way to accomplish this without sagas?

I see the following possibilities with axon.

  1. Use a saga. the saga is started when the user is created and is associated with that specific aggregateid. when an issue is associated with the User the saga keeps track of that issue. now when something of interest happens in the user, the saga can subscribe to that event and “forward” it via a command to the “registered” Issues. Here the saga keeps track of the issues. is there a limit on the number of sagas? should there be forever living sagas?
  2. The User also tracks the associated issues (this is what i try to avoid) and publishes them in the event. so an eventhandler or saga can transform commands to the Issues out of this information.
  3. I just publish the event and the event handler / saga searches (via a dedicated lookup model or maybe the read model) for associated Issues. It then sends commands to the identified Issues.

Is there another maybe easier possibility that i am missing?

Thanks and best regards
Patrick

P.S.: i am using axon 3.4.2

2

Hi Patrick,

just my 2 cents:

1. I'd advise against a "saga as a lookup table" - migration might get
fairly complicated over time and there's a bunch of state that needs
some kind of attention; probably nothing should live forever
2. I'd advise against a "aggregate as lookup table", because the point
of an aggregate is to decide which business facts happened; besides
wouldn't this thing need to live forever, too?
3. Dedicated lookup table sounds like a reasonable solution: purely
based on distilled business facts, does not add (operational) state,
does not "live" at all, can be optimised, replayed, etc.

Depending on the exact use case: for short transactions no 3) would
work with a command spawning further commands, too.

Cheers,
Michael