asmhatre/spring-messaging-demo
1
0
Fork 0
Code Activity

Add the saga module: Saga Pattern in Spring Boot, orchestration vs choreography with Kafka

Browse Source
This commit is contained in:
Claude
2026-10-03 19:56:40 +00:00
parent c1b40b0db9
commit 4a5d3318bf
44 changed files with 1296 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
saga/output/02-orchestration-saga.txt
+20
View File
@@ -0,0 +1,20 @@
$ mvn -pl saga test -Dtest=OrchestrationSagaTest
(the same two scenarios -- enough stock, and not enough stock -- run through
OrderSagaOrchestrator instead of through independent listeners)
[happy path] Order 1 status: CONFIRMED
[happy path] Stock remaining for GADGET-ORCH-OK: 8
[happy path] Payment record status: RESERVED
[compensation] Order 2 status: CANCELLED
[compensation] Stock remaining for GADGET-ORCH-FAIL (untouched): 1
[compensation] Payment record status: REFUNDED
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Same outcomes as the choreography transcripts, reached a structurally different way. Here,
PaymentOrchestrationHandler and InventoryOrchestrationHandler never decide what happens next --
they carry out exactly one command each and reply. OrderSagaOrchestrator is the only class that
reads a reply and decides what command to send next, including the decision, in the second
test, to send RefundPaymentCommand once InventoryReply says no. Compare this transcript's two
tests with the two choreography transcripts above: identical business outcomes, from listener
classes that know nothing about the saga as a whole versus one class that knows all of it.