Fixing choreography issues: Ordering<->Inventory

[pjurewicz]

There are some design issues with choreography across bounded contexts.

• We change multiple aggregates within a single transaction
• They comes from different bounded contexts
• We rely on synchronous event handlers. Exception in one BC rollbacks the whole transaction

We want to eliminate them, starting with Ordering and Inventory BCs. OrderingProcess needs to be introduced. Goal architecture:

After going fully async, we will need to take care of UI. Changes from domains can be broadcasted to the users asynchronously with turbo streams (just like read model).

[pjurewicz]

Adding an item may be a process too.

[pjurewicz]

I've been thinking about it for some time. In fact, when an item is added to the cart, we check its availability only for UX reasons. In this step, no reservation is made. Aggregate's step stays unchanged. I can see now that the currently existing CheckAvailability command does not make sense. We can safely move this checking to the read model. Updated diagram:

[pjurewicz]

This one is almost done. However, I am wondering now if it is not too complicated. In fact, Reserve and CancelReservation operations will always be synchronous. We always do commands in a synchronous manner. So that, StockReserved and CanceledStockReservation do not need to invoke ReservationProcess. We already know if it succeeds or not when we dispatch the reserve command.

Let's try to simplify this.

[pjurewicz]

Merged to master. Now it is time to go async with this process.