can I ask if applying an event in another event handler common pattern? Or should it be avoided as much as possible? Maybe I am little confused about whole CQRS concept :(, but I am trying to implement something what is really driven by events. I think CQRS and ES is
perfect fit but maybe I am wrong. Is it completely wrong that my aggregate state is internally driven by events?
I try to describe my problem a little. I have Player aggregate and I send command to that player: new ChangeExperience(playerId, +1500) … now, when command handler calls PlayerAggregate.changeExperience(amount) methods, following events are
applied (alignment means event nesting)
-> ExperienceChanged(playerId, +1500) // current experience is 1500 and for next level is needed 100xp, so levelUp is raised and -100xp is subtracted
-> LevelUp(playerId, +1) // when player levelUp to 1st level, some his stats are increased
-> VitalityChanged(playerId, +2)
-> StrengthChanged(playerId, +1)
-> ExperienceChanged(playerId, -100) // curren experience is 1400 and for next level is needed 200px
->LevelUp(playerId, +1) // when player reaches level 2, he learns a new spell fireball
-> SpellLearned(playerId, “fireball”)
-> ExperienceChanged(playerId, -200)
… and so on
So basically, one command can cause a lot of events and each event can starts another events. All this process should be consistent and done in single unit of work. Do you think that CQRS and ES is absolutely wrong choice here? If so, can someone recommend me
some architecture/technology/framework etc… where something like this can be easily implemented? Thank you very much.
PS. I am sorry that there is more similar post from me, but I am hopeless.
Noob here as well, but the whole thing does not look too good to me.
Some examples:
ChanceExperience is rather strange for a command. Surely it is not ok for users to just ask the system to increment their experience.
A lot of state changes are implicit in the ExperienceChanged event and should be published as events only if they are meaningful to the domain or necessary for other sagas/event handlers. Otherwise your code knows what to do at each level, and it can just do it within the aggregate.
I would not say that CQRS or ES are the problem, domain design is. What information you need to do your decisions and how to handle concurrency and consistency are the issues.
Take that with a grain of salt. I hope I could be of help
ChangeExperience command is here only for example. Real scenario is more complicated. For example user can complete quest or kill a monster and earn experience as reward and it can start an event stream like that.
These events should be both published (for UI to be reactive and for another event handlers which can react) and used to change internal aggregate state and should be stored in event store (useful for log, reports, mining, statistics etc…).
However, It’s true that some of that events aren’t so important in domain (I mean, that aggregates logic don’t depend on them) and can be only published (but then it won’t be stored and I lose it’s advantages)
Dne čtvrtek 13. srpna 2015 21:28:59 UTC+2 Andrea Ratto napsal(a):
it’s very normal to have some events applied in an aggregate that the aggregate itself isn’t interested in. Simply don’t add an @EventSourcingHandler for it.
Since Axon 2.4, it’s also ok to apply an event inside another event handler. That allows your aggregate to trigger behavior based on events as well. Axon will know when to ignore these calls (e.g. when sourcing an aggregate from events) or when to apply it (when the aggregate is handling a command). If you have complex behavior that depends on the “live” state of an aggregate, you can call “isLive”.