Doesn’t it seems like a valid use case where when an event is triggered it should trigger other commands in action in a persistent entity IMPLICILTY?
I understand that we could have a event listener which can again send a follow up command to the persistent entity. This however seems like a lot of boilerplate to me. A PersistentEntity actor may always end up having a listener for such uses cases!
Let’s say releasing an employee should trigger cancelling leaves “implicitly” in a leave management domain?
How about sending ReleaseEmployee and CancelLeaves to the persistent entity actor one after the other? How can we do that?
Is there any better to achieve this? What are design practices around this?
Does it go to the same entity? If so, I don’t think you should send two comments, but one single command that emits two events. ReleaseEmployee => Seq(LeavesCancelled, EmployeeReleased).
Having chains of commands being handled by the entity would not give you atomicity or any guarantee. If the server shutdowns after the first command but before the second command, the second command will be lost.
To conclude, if you need interaction between two different entities, then the best choice is to listen to the events in an at-least-once fashion. If it’s about operations on the same entity, it’s better to emit more than one event for a single command.
I now understand your reasoning around “why” two commands should not be send to a persistent entity and exactly as you suggested ReleaseEmployee => Seq(LeavesCancelled, EmployeeReleased). is what I am doing in my project.
But what I am trying to understand now is that the code that handles UpdateIntimation/CancelIntimation/CreditLeaves has already been written as part of handling those commands. Now for every new command such as ReleaseEmployee that may also need to handle CreditLeaves, say for instance, seems to have to rewrite handling it.
Since it involves ctx and persisting events as part of handling each command, (1) what are better way to refactor those common “COMMAND” codes? (2) Also, could be please point out an example code that involves refactoring persistent entities? It get’s long and unmaintainable with all the “ACTIONS” handled within the same class.