2
votes

What is the best way to get the updated representation of an entity after mutating it with a command.

For example, lets say I have a project like digital-restaurant and I want to be able to update a field on the restaurant and return it's current state to the client making the update (to retrieve any modifications by different processes).

When a restaurant is created, it is easy to retrieve the current state (ie: the projection representation) after dispatching the create command by subscribing to a FindRestaurantQuery and waiting until a record is returned (see Restaurant CommandController)

However, it isn't so simple to detect when the result of an UpdateCommand has been applied to the projection. For example, if we use the same trick and subscribe to the FindRestaurantQuery, we will be notified if the restaurant has been modified, but it may not be our command that triggered the modification (in the case where multiple processes are concurrently issuing update commands).

There seems to be two obvious ways to detect when a given update command has been applied to the projection:

  1. Have a unique ID associated with every update command.
    • Subscribe to a query that is updated when the command ID has been applied to the projection.
    • Propagate the unique ID to the event that is applied by the aggregate
    • When the projection receives the event, it can notify the query listener with the current state
  2. Before dispatching an update command, query the existing state of the projection
    • Calculate the destination state given the contents of the update command

In the case of (1): is there any situation (eg: batching / snapshotting) where the event carrying the unique ID may be skipped over somehow, preventing the query listener from being notified?

Is there a more reliable / more idiomatic way to accomplish this use case?

Axon 4 with Spring boot.

1

1 Answers

2
votes

Although fully asynchronous designs may be preferable for a number of reasons, it is a common scenario that back-end teams are forced to provide synchronous REST API on top of asynchronous CQRS+ES back-ends.

The part of the demo application that is trying to solve this problem is located here https://github.com/idugalic/digital-restaurant/tree/master/drestaurant-apps/drestaurant-monolith-rest

The case you are mentioning is totally valid.

I would go with the option 1.

My only concern is that you have to introduce new unique ID associated with every update command attribute to the domain (events). This ID attribute does not have any Domain/Business value by my opinion. There is an Audit(who, when) attribute associated to every event already, and maybe you can use that to correlate commands and subscriptions. I believe that there is more value in this solution (identity is part of domain), if this is not to relaxing for your case. Please note that Queries have to be extended with Audit in this case (you will know who requested the Query)