These are chat archives for RBMHTechnology/eventuate

18th
Nov 2016
Martin Krasser
@krasserm
Nov 18 2016 08:19

@mehrentreich 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.

Nino Ulsamer
@ulsamern
Nov 18 2016 08:58
Hi guys, we discovered Eventuate a few days ago and are thinking about using it to power the trading infrastructure for our new FinTech startup. It's a greenfield project and we are internally debating whether to use Java or Scala for building our microservices. In terms of using the Eventuate API, is there any difference between the two (such as one being preferred over the other because it is updated more frequently, integrated in a better way, etc.)? Thanks a lot for your input!
Martin Krasser
@krasserm
Nov 18 2016 09:18
@ulsamern welcome and glad to hear that you think about using Eventuate! We plan some changes to the Java API in the future because of the improved Java integration with the recently released Scala 2.12. Anyway, the Java API is a first class citizen in Eventuate and we continue to support it in the future.
Nino Ulsamer
@ulsamern
Nov 18 2016 09:20
@krasserm thanks for the reply. so you are implying that in fact as Scala is Eventuate's native platform it would probably be the better choice (all other factors being equal) to use, right?
Martin Krasser
@krasserm
Nov 18 2016 09:23
@ulsamern when in doubt yes :smiley: but we intend to support both APIs equally well. We follow more or less the same strategy as Akka does with its Java API.
Nino Ulsamer
@ulsamern
Nov 18 2016 09:25
@krasserm ok, got it. thanks! :smile: also, initially I got a bit confused by the naming overlap with eventuate.io. But I guess both projects have nothing to do with each other except for sharing the name?
Martin Krasser
@krasserm
Nov 18 2016 09:26
@ulsamern exactly
Marco Ehrentreich
@mehrentreich
Nov 18 2016 14:43
@krasserm thanks a lot for the detailed explanation
that was a precious hint that aggregate ID in the context of Eventuate doesn't mean exactly the same as an aggregate ID in DDD
regarding the need to publish events to other, unknown actors you're probably right
as I already said that is no limitation for my use cases as I know the ID of the "communication partners" in question
and I can see your point that an EventsourcedView is probably the more appropriate concept to handle events from many different actors
Marco Ehrentreich
@mehrentreich
Nov 18 2016 14:49
@ulsamern I have not that much experience with Eventuate (and Akka) yet
I have some experience with Scala and at lot with Java but I'd highly recommend to go with Scala if your team is willing to learn a different language (if they aren't familiar with Scala)
it takes some time to getting used to but it helps to vastly reduce a lot of (boilerplate) code
it has some features like pattern matching which are particularly useful when working with actors
Marco Ehrentreich
@mehrentreich
Nov 18 2016 14:54
working with actors in Java is really ugly although it is possible and Akka/Eventuate explicitly provides a Java API
but that's just my 2 cents