These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
EventsourcedActors are indeed the right choice to implement aggregates.
EventsourcedActors with the same
aggregateId form a default collaborator group that can exchange events based on event routing rules. A collaborator group can be replicas of the same
EventsourcedActor type to achieve state replication or a group of different
EventsourcedActors that collaborate to achieve a common goal, for example. So the
aggregateId concept of Eventuate is more general than that of DDD.
customDestinationAggregateIds can be used to route messages between collaborator groups. These routing is persisted so that it can be repeated on event replay. This is suitable for point-to-point event communication or a multicast to a small number of destinations. Currently, only
Eventsourced* components with an undefined
aggregateId can receive events from any other emitter. Publishing to an unknown set of actor with a defined aggregate id is not supported (yet).
On the other hand, think about if publishing to all
EventsourcedActors may be better modeled by a separate
EventsourcedActor with an undefined
aggregateId that maintains a write model distinct from those of the individual aggregates. If you find that this extra actor doesn't event need to handle commands, you have a good hint that it's actually a view. You can still have causal consistent reads from a view and an actor using conditional requests for example. Hope that helps.