I have three suggestions:
In order to make use of ACID transations and avoid dual writes it might be beneficial to support something like the Outbox pattern.
I already started some discussions some years ago:
- The outbox pattern - #10 by Oliver_Libutzki
- Consistency gap in conjunction with state-stored aggregates · Issue #1103 · AxonFramework/AxonFramework · GitHub
Somehow related, but with another focus:
We would like to have a native option to decide if a certain event should be exposed to the outside world or should only be visible and usable within a certain module / bounded context.
@Simon_Zambrovski, @Steven_van_Beelen and I already discussed this topic in the Contributions section. Although there has not been any action in the last couple of months the topic is still relevant for us. (For those who are allowed to see the thread: https://discuss-next.axoniq.io/t/local-event-store-support/2980)
From a conceptual point of view the append-only Event Store is a great idea. Unfortunately in our projects we experienced that this leads to problems for us. Sometimes it’s not feasable to extend the upcaster chain in order to evolve our events. In the context of GDPR we sometimes wish there was a solution to anonymize data in old events.
I know that “changing” the event store and therefore the history comes with its own flaws, but I just would like to share that having an append-only event store sometimes leads to cumbersome solutions and rewriting history in certain cases is much more pragmatic.
That being said we highly appreciate your work and there are a lot of ongoing improvements in the 4.x stream.
Especially the “Dead letter queue” is something that I would have requested for 5.x if it would not be planned for 4.x.