Then we can reduce saga by 1 transaction and create tickets in APPROVED status already (so we can remove the workflow of approving tickets as well).
Does it make sense for CreateOrderSaga?
Or in the case if you need to have 6 steps in CreateOrderSaga for educational purposes, then will such saga optimization make sense in real-life project?
PS. Also, as from business perspective - as for me, it would be more logical to create some objects in other services AFTER the order is completelly validated and confirmed - to not to have to delete/reject these objects if order happens to be not valid. What's your opinion on that?
Hi Chris,
I have a question regarding CreateOrderSaga.
Let's review Fig. 4.2 (page 115). Here is current sequence of transactions:
Tx1 - OrderService - createOrder() Tx2 - ConsumerService - verifyConsumer() Tx3 - KitchenService - createTicket() Tx4 - AccountingService - authorizeCard() Tx5 - KitchenService - approveTicket() Tx6 - OrderService - approveOrder()
What if we swap Tx4 and Tx3 and combine old Tx3 and Tx5 in KitchenService? The sequence will be:
Tx1 - OrderService - createOrder() Tx2 - ConsumerService - verifyConsumer() Tx3 - AccountingService - authorizeCard() Tx4 - KitchenService - createTicket() AND approveTicket() Tx5 - OrderService - approveOrder()
Then we can reduce saga by 1 transaction and create tickets in APPROVED status already (so we can remove the workflow of approving tickets as well).
Does it make sense for CreateOrderSaga? Or in the case if you need to have 6 steps in CreateOrderSaga for educational purposes, then will such saga optimization make sense in real-life project?
PS. Also, as from business perspective - as for me, it would be more logical to create some objects in other services AFTER the order is completelly validated and confirmed - to not to have to delete/reject these objects if order happens to be not valid. What's your opinion on that?
Thanks