Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fixing choreography issues: Ordering<->Inventory #225

Closed
pjurewicz opened this issue Jan 17, 2023 · 4 comments
Closed

Fixing choreography issues: Ordering<->Inventory #225

pjurewicz opened this issue Jan 17, 2023 · 4 comments
Assignees
@pjurewicz

Comments

@pjurewicz
Copy link
Collaborator

pjurewicz commented Jan 17, 2023 •
edited
Loading

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:
exploring ecommerce-4

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
Copy link
Collaborator Author

Adding an item may be a process too.

exploring ecommerce-5

@pjurewicz
Copy link
Collaborator Author

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:
exploring ecommerce-6

@pjurewicz pjurewicz self-assigned this Jan 20, 2023
pjurewicz added a commit that referenced this issue Jan 24, 2023
@pjurewicz
made process around reservation
f92be73 
- it fixes some choreography issues described wider in #225
- it simplifies Inventory BC a lot. Reservation aggregate is gone.
- it eliminates SyncInventoryFromOrdering set of event handlers from processes
- it complicates Ordering::Order a bit because it requires an additional step
   - I wanted to distinguish between OrderSubmitted and OrderPlaced
   - It was easier to introduce OrderPreSubmitted next to already existing OrderSubmitted for now
   - Ordering codebase will be improved in next step
- needs test for mutation coverage
- needs to go async
@pjurewicz
Copy link
Collaborator Author

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.

exploring ecommerce-7

pjurewicz added a commit that referenced this issue Jan 26, 2023
@pjurewicz
I reversed some design decision to simplify Reservation process
bfba109 
Details here: #225 (comment)
@pjurewicz
Copy link
Collaborator Author

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

This was referenced Jan 26, 2023
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pjurewicz pjurewicz

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pjurewicz