search

AxonFramework / AxonFramework

Framework for Evolutionary Message-Driven Microservices on the JVM
https://axoniq.io/
Apache License 2.0
3.43k stars 802 forks source link

Improve support for a local event store #1342

Open OLibutzki opened 5 years ago

OLibutzki commented 5 years ago

Note: This is more or less an epic in order to collect the ideas and tasks for supporting a local event store.

Especially when using EventSourcing it would be very helpful to explicitly define which events are just meant to be used within a bounded context and which events are used to communicate with the outside world (the public API). Last year I wrote a blog post to explain this approach.

By default, the Axon Framework, publishes all the events to the very same event store. We would like to have a local event store in the bounded context which persists the local events. We built a solution which allows us to annotate certain events with @LocalEvent in order to restrict them to the usage within a bounded context. There is a special EventStore which dispatches the events to their intended destination (local event store / global event store). You can find the implementation here (branch local-event-store).

As discussed in your office it might be better to store those events in the local event store and have transformation capabilities to transform one or a couple of local events into a global event.

Matthias Verraes describes these patterns quite well: http://verraes.net/2019/05/ddd-msg-arch/ What I talk about in this context are summary events.

Having such a solution would not only help in an event sourcing scenario. It might also "fix" the consitency gap when using State-stored aggregates I explained in #1103. First of all you save all events to a local event store (ACID transaction). Then these events (as-is or transformed) are published to a global event store.

This whole concept is fundamental for our architecture and in my opinion it would boost the Axon Framework a lot to have this "in the core".

OLibutzki commented 4 years ago

In the meantime we are one or two steps further.

We got some (production) experience with our solution and we were able to solve a couple of issues.

If you are interested I could share our ideas and experiences and maybe it's something you consider including in the Axon Framework core.

smcvb commented 4 years ago

Any insights in resolving this issue are always much appreciated @OLibutzki! So if you can find the time to provide gotcha's, sample implementations, or even a PR, that would be amazing.

OLibutzki commented 4 years ago

Hi @smcvb,

as it takes some time to extract the implementation from our internal code base it might make sense to have a chat about the ideas and strategy via Teams, Zoom whatsoever in the first place.

smcvb commented 4 years ago

That wouldn't be too weird an idea. For smaller things, we've tended to move to our forum. We've got a dedicated section for contributors where I could add you too for discussions like this.

OLibutzki commented 4 years ago

Ok, I'm fine with that suggestion.

OLibutzki commented 4 years ago

Hi @smcvb,

I finally found the time to put all the stuff we did into a GitHub Repo: https://github.com/OLibutzki/axon

Although we already run this solution in production I would call it an early draft and a basis for discussion.

I tried to add a README for each aspect. the best entrypoint is the README in the repository root.

Feel free to crawl the repo by yourself. If you have any questions feel free to ask me.

Kind regards Oliver

smcvb commented 9 months ago

Added this issue to release 5.0.0 as we intend to validate the feasibility of this in the new APIs.

OLibutzki commented 9 months ago

@smcvb in case you need any feedback / sparring partner, feel free to contact me.

smcvb commented 9 months ago

@smcvb in case you need any feedback / sparring partner, feel free to contact me.

Thanks a bunch, @OLibutzki! When the time is right, and we end up to be stuck or want to validate the approach, I'll be sure to reach out. :+1: