devlooped
Command Handling questions
Command handling often requires dependency injection to perform tasks associated with, for example, validating a command and kicking off other processes.
For example, handling the ChangeEmail command might involve first checking an injected EmailReservationService to verify the email isn't already taken by another user.
Grain state can't get services injected. Therefore the actor classes as used in this opinionated framework also cannot use injected services to validate/handle their commands.
Therefore I write a UserCommandHandler class separately from the UserAggregate (state) class. A command comes to the event-journaled UserGrain which has reconstructed the UserAggregate from past events, and has had the UserCommandHandler injected. It then passes both the state and the command to the UserCommandHandler, which goes through all the hoops associated with validating and processing a command including calls to other injected services. Then the command handler returns an IEnumerable containing all the events to be applied to the state/journaled grain.
I'm VERY interested in seeing where this project goes, but I'm afraid for me at the moment, there's not the correct wiring between the grain, the state and injected services yet. Thank you. And I'm really happy to demo further if you're interested in knowing how I work. And if you can simplify me, that'd be good too :)
EventSourced objects maintain a sequential event count as you know. All my command objects have an "ExpectedVersion" property so the command handler can reject the command if the grain state has already moved on due to concurrent commands from elsewhere.
To make things smoother, my actor grains return the state's new version id after every command, successful or not.
Excelent point about DI for the domain class. Will need to think about it a bit more.
On returning the state's version from each command execution, that sounds like a reasonable thing to do. I think the library doesn't need to make that decision for you though, right?
Quick question: would you rather have the injected state into the domain class or would you still prefer to have a separate command handler thing that does that? I think richer domain classes are better...
I now support arbitrary services injected in the actor constructor, just as you'd expect from a DI-powered activation. The id is still passed to the constructor as a string (separate issue for that).