I need to demonstrate the event sourcing capabilities of Axon in my POC prototype, and that includes replaying events in case of a failure. Since this is only a prototype I am using the most simple infrastructure possible, i.e. no database, no queues, only a simple war deployed on a tomcat.
So my question is, how can I replay events from a FileSystemEventStore, and without using the ReplayingCluster?
Or is there a way to wrap a ReplayingCluster around a FileSystemEventStore?
Somehow related to this, While I was searching this group I read somewhere that “returning values from commands in aggregates is a bad practice”. Why is that? My prototype relies on this, my usecase is somehow like this:
the FilesystemEventStore doesn’t support replaying. You can only store and load events for a single aggregate. I believe it also supports snapshots, but that’s really it.
You’re probably better off using the JpaEventStore with an hsql database. At least, you’ll have all the options.
it’s not really clear to me how ‘H’ executes the intent of C. That’s really the job of A. Or is the handler a command handler inside the aggregate?
It is seen by some to be good practice not to rely on return values from commands. Especially in distributed systems, it’s unreliable and slow to have to wait for the reply of a command. However, in Axon, sending a return value is really easy. In your command handler, simply define a return type and return the value you want. The callback will receive this value as the parameter of the onSuccess() method.
However, if the system crashes (assuming the transaction has just been committed, but return value was not yet sent), the return value will never reach the sender. When using the distributed command bus, the sender will receive an exception, telling it that the host executing the command was lost. If your commands are idempotent (or if you have some other means of detecting duplicate commands), you can simply send the command again to some other node.
Actually what I really wanted is load events for a single aggregate, so I just did it with the FS Store. We are not planning (at least not for now) to have a full-fledged EP system, but instead using EP for recovery on “short” term tasks (like I described in “SYSTEM RECOVERS —> replay E1-E4”) so when such task finishes the Events associated wit it are discarded.
it’s not really clear to me how ‘H’ executes the intent of C. That’s really the job of A. Or is the handler a command handler inside the aggregate?
Actually I’m banging my head against several walls with this. Basically the question is, where should I put the “real” work inside the architecture? Aggregates, EventHandlers, CommandHandlers, Sagas? I actually already did it in several ways but none feel “natural” to me and they feel too complex… Let me try one example with my “audit” prototype: after the Aggregate is created with a CreateAudit (that only sets it’s Id) the user invokes a StartAudit
When a command handler requires certain information, it is almost always best to provide it as part of the command itself. If the information is too large to pass in its entirety, you can consider giving the aggregate access to a service (in ddd terms a repository) that can provide access to the required instances.
The service can be injected by adding it as parameter to the @CommandHandler annotation. If it’s a Spring bean, Axon will inject it (if there is exactly one instance in the application context).
Aggregates themselves will never send out commands directly.
OK, got it as well. However… why to inject the service as a parameter in the method and not in the Aggregate itself as “usual”? (the way I posted in another threas)
BTW, funny enough I had sent that link to my boss a couple of hours before you posted it Let’s see what direction we are going to take after the “prototype” phase, I may try to push for it…