event-sourcing

Not your fault: the literature is a mess.

Domain events, event sourcing, and event driven are three different ideas that happen to share the label "event".

Domain events are a domain modeling pattern; in effect making "things that happen" a first class citizen in your domain model. Think BookSold, not MouseClicked

Event sourcing is a data modeling pattern; instead of having a domain entity with mutable properties, we have a domain entity with a history of changes.

Event driven is a communication pattern; system A publishes an event, and system B reacts. Notice that system A and system B don't even need to know about each other; the only need a common undertanding of the event, and shared plumbing (aka middleware).

In CQRS, when using EventStoreDb, your aggregate must be designed to be restored to a state from Events. Events are stored in a stream with a unique name and identifier (guid). When modifying the aggregate, you must read this stream, and apply each event in sequence to restore the current state, before executing any changes to the aggregate (which generates more events). In order to maintain integrity and handle optimistic concurrency, you should have a simple version check in your aggregate which counts the old events + new events to ascertain to latest version number to be persisted.

The issues I see above are as follows. Your aggregate has a constructor and a static method which generates events without any validation of the current state i.e.: What happens if I call create twice with the same guid?

this.apply(new UserCreatedEvent(guid, {email, name}, new Date()));

You are applying state here directly. Instead, you should raise the event inside your Create method.

this.raiseEvent(new UserCreatedEvent(guid, {email, name}, new Date()));

This should be implemented to do the following.

• Added to a list of uncommitted events
• this.apply called

You should then persist the events to the EventStoreDb in your command handler.

Event Source is not replacing the DB. It has some benefits and challenges. So, we should choose it wisely. If you are not comfortable then don't choose it. You can implement Microservice Style without event sourcing.

Query able DB - Simple solution is to implement CQRS pattern and keep your Query DB in sync with Event Source DB.

Event DB should be with owner service like if you are keeping events about Order than it should be in Order service. (Yeah, other service can have replica of the same).

You may use Kafka as intermediate storage for event but not the final one.

CQRS is not about one DB. It an pattern where we use to DB models, one is for Command and Another one is for Query.

If you understand Java then please refer Book "Microservice Patterns - Chris Richardson" and if you are from C# or Microsoft technology stack then you may refer "https://github.com/dotnet-architecture/eShopOnAzure".

You are mixing some concepts. Let's clarify them.

If you implement event sourcing, it means that your source of truth is the events themselves. You store events, not a concrete "state" (an entity). Let's see some pseudo-code:

To create a new account:

The CQRS module registers the EventHandlers automatically by looking at the providers list. By using EventBus.register() we can add additional subscriptions.

This commit resolves the issue.

By removing the EventHandlers list from EventBus.register(), I was able to subscribe to them only once and hence resolve the duplicate message issue.

One question that comes to mind is, is REST the right paradigm for CQRS at all?

One completely different way to structure this is to not have action-focused endpoints, but instead structure your REST API as a series of events that you add new events to (with POST).

Events should be immutable and append-only, so maybe a DELETE method doesn't make that much sense for mutations.

If you're going all in with CQRS (good luck, I've heard the war stories) I would be inclined to build an API that reflects that model well.

First off, and not completely tailored towards your question, you're referring to the Axon Extensions to enable distributed messaging. Although this is indeed an option, know that this will require you to configure several separate solutions dedicated for distributed commands, events and event storage. Using a unified solution for this like Axon Server will ensure that a user does not have to dive in three (or more) different approaches to make it all work. Instead, Axon Server is attached to the Axon Framework application, and it does all the distribution and event storage for you.

That thus means that things like the DistributedCommandBus and SpringAMQPPublisher are unnecessary to fulfill your goal, if you would use Axon Server.

That's a piece of FYI which can simplify your life; by no means a necessity of course. So let's move to your actual question:

Is this a valid approach?

I think it is perfectly fine for a Saga to act as a anti corruption layer in this form. A Saga states that it reacts on events and send operations. Whether those operations are in the form of commands or another third party service is entirely up to you.

Note though that I feel AMQP is more a solution for distributed events (in a broadcast approach) than that it's a means to send commands (to a direct handler). It can be morphed to suit your needs, but I'd regard it as suboptimal for command dispatching as it needs to be adjusted.

Lastly, make sure that your Saga can cope with exception from sending those operations over RabbitMQ. You wouldn't want the Invoice service to fail on that message and having your Order service's Saga think it's on a happy path with your transaction of course.

Concluding though, it's indeed feasible to use another message broker within a Saga.

Is there a documented way of handling this kind of scenario in Axon?

There's no documented Axon way to deal with such a scenario at the moment, as there is no "one size fits all" solution. From a pure Axon approach, using commands would be the way to go. But as you stated, that's not an option within your domain due to an (unwilling?) other team. Hence you would track back to the actual intent of a Saga, without taking Axon into account, which I would summarize in the following:

• A Saga manages a complex business transaction.
• Reacts on things happening (events) and sends out operations (commands).
• The Saga has a notion of time.
• The Saga maintains state over time to know how to react.

That's my two cents, hope this helps you out!

My question then is: can't I just save from the RootActor two events, one for self, and one for a target BranchActor?

No. Not to sound trite, but the only thing you can do to an actor is to send a message to it. If you must do what you are doing you are doing, you are on the right path. (e.g. pipeTo etc.)

is this even a good practice for event-sourcing?

It's not a good practice. Whether it's suboptimal or a flat out anti-pattern is still debatable. (I feel like I say say this confidently because of this Lightbend Discussion thread where it was debated with one side arguing "tricky but I have no regrets" and the other side arguing "explicit anti-pattern".)

To quote someone from an internal Slack (I don't want attribute him without his permission, but I saved it because it seemed to so elegantly sum up this kind of scenario.)

If an event sourced actor needs to contact another actor to make the decision if it can persist an event, then we are not modeling a consistency boundary anymore. It should only rely on the state that [it has] in scope (own state and incoming command). … all the gymnastics (persist the fact that its awaiting confirmation, stash, pipe to self) to make it work properly is an indication that we are not respecting the consistency boundary.

If you can't fix your aggregates such that one actor is responsible for the entire consistency boundary the better practice is to enrich the command beforehand: essentially building a Saga pattern.

How the compensation events are generated should be the concern of the Story aggregate (after all, that's the point of an aggregate in event sourcing - it's just the validator of commands and generator of events for a particular stream).

Presumably you are following something like a typical CQRS/ES flow:

• client sends an Undo command, which presumably says what version it wants to undo back to, and what story it is targetting
• The Undo Command Handler loads the Story aggregate in the usual way, either possibly from a snapshot and/or by applying the aggregate's events to the aggregate.
• In some way, the command is passed to the aggregate (possibly a method call with args extracted from the command, or just passing the command directly to the aggregate)
• The aggregate "returns" in some way the events to persist, assuming the undo command is valid. These are the compensating events.

• compute the compensation event for each of the occurred events

...

Unfortunately, the second step of the previous procedure is not always possible

Why not? The aggregate has been passed all previous events, so what does it need that it doesn't have? The aggregate doesn't just see the events you want to roll back, it necessarily processes all events for that aggregate ever.

You have two options really - reduce the book-keeping that the aggregate needs to do by having the command handler help out in some way, or the whole process is managed internally by the aggregate.

Command handler helps out: The command handler extracts from the command the version the user wants to roll back to, and then recreates the aggregate as-of that version (applying events in the usual way), in addition to creating the current aggregate. Then the old aggregate gets passed to the aggregate's undo method along with the command, so that the aggregate can then do state comparison more easily.

You might consider this to be a bit hacky, but it seems moderately harmless, and could significantly simplify the aggregate code.

Aggregate is on its own: As events are applied to the aggregate, it adds to its state whatever book-keeping it needs to be able to compute the compensating events if it receives an undo command. This could be a map of compensating events, pre-computed, a list of every previous state that can potentially be reverted to (to allow state comparison), the list of events the aggregate has processed (so it can compute the previous state itself in the undo method), or whatever it needs, and it just stores it in its in-memory state (and snapshot state, if applicable).

The main concern with the aggregate doing it on its own is performance - if the size of the book-keeping state is large, the simplification of allowing the command handler to pass the previous state would be worthwhile. In any case, you should be able to switch between the approaches at any time in the future without any issues (except possibly needing to rebuild your snapshots, if you have them).