These are chat archives for RBMHTechnology/eventuate

Nov 2016
Marco Ehrentreich
Nov 17 2016 19:39
@krasserm that makes me feel a little bit better :-)
unfortunately I have still some trouble to map the concepts from Eventuate to my understanding of CQRS
as far as I understand the concept of CQRS and event sourcing the usual way to update an aggregate instace of the same or different type of another aggregate instance would be to consume the domain events the other aggregate instance emits (in reaction to a command processed by this other aggregate instance)
I'm not talking about views for the read model side of CQRS here but the write side
but if I model DDD aggregates with EventsourcedActors which each have a unique aggregate ID for each aggregate instance I have a problem with solution
Marco Ehrentreich
Nov 17 2016 19:44
because Eventuate takes care that each actor only receives events which match its own aggregate ID
this seems to make it impossibele to consume domain events of another EventsourcedActor (with a different aggregateId) inside the onEvent handler of my EventsourcedActor in question
maybe it's a false assumption that I can model aggregates in DDD as EventsourcedActors and apply the patterns of CQRS and event sourcing but I guess I'm just doing it wrong
everything else works really nice and perfectly matches my understanding of CQRS
Marco Ehrentreich
Nov 17 2016 19:49
I hope this problem description makes it clear what I am trying to achieve
Marco Ehrentreich
Nov 17 2016 20:38
just found the customDestinationAggregateIds in the persist() method which probably would work for my use case because I know the aggregate ID's of the other aggregate instance(s) which should be updated in an eventually consisten manner via domain events
is there also a way to tell an EventsourcedActor to publish its resulting domain events to potentially unknown (or all) interested EventsourcedActors?