Event Sourcing without Aggregates

Imported from Google Groups
1

Hi all,

This might be a strange question, so bear with me…

I might be starting a new project soon for which I think Event Sourcing is a good fit. I’ve used Axon and Event Sourcing before and was happy with the experience but this next project doesn’t have a lot of business logic in the traditional sense. The application will be mostly listening to a lot of remote systems which send a lot of data which I’d like to persist in something akin to an Event Store and I’d like to distribute this data to Event Listeners. In the future I’d like the flexibility of replaying the Events to these Event Listeners but creating Commands and Aggregates just to store Events just doesn’t feel right. The Commands would do nothing and the Aggregate would just map these Commands one-to-one to Events.

Is it possible to use Axon’s Event Sourcing features without Commands and Aggregates? Does anyone have any experience with this? If Axon isn’t the right fit for this type of project, what libraries or frameworks should I investigate or should I go the DIY route?

Thanks in advance!

Regards,

Dennis

2

Hi Dennis,

you can use the EventStore without using anything else. However, you will need to append DomainEventMessages to it. These message contain an aggregate identifier and sequence number. This aggregate identifier could be an arbitrary value (I have seed the UUID cafebabe-cafe-babe-cafe-babecafebabe more than once), but you will still need to assign an incremental sequence number to it.
In Axon 3, the design of the EventStore API (not so much the storage format) will change. In that version you will be able to append EventMessages (so without the aggregate identifier) as well. I am not sure if you can wait for Axon 3 to appear for this project. I am currently estimating the release at end 2015, beginning 2016, depending on howmany PR’s I receive :wink:

Cheers,

Allard

3

Hi Allard,

Thanks. We probably can’t wait for Axon 3 but we’ll definitely evaluate Axon 2 for this.

Regards,

Dennis