이 클래스에는 orderService, createOrderSagaManager, createOrderSaga, orderCommandHandlers, orderCommandHandlersDispatcher 등 다양한 스프링 빈이 정의되어 있습니다. 또 kitchenService Proxy, orderServiceProxy 등 프록시 클래스를 가리키는 스프링 빈도 있습니다.

CreateOrderSaga는 주문 서비스의 여러 사가 중 하나일 뿐입니다. 기타 여러 시스템 작업 역시 사가를 활용합니다. 예를 들어 cancelOrder()는 주문 취소 사가, reviseOrder()는 주문 변경 사가를 사용합니다. 그러므로 여러 서비스가 REST, gRPC 같은 동기 프로토콜을 사용하는 API를 통해 외부와 통신하지만 서비스 간 통신은 절대 다수가 비동기 메시징을 사용할 것입니다.

지금까지 보다시피, 마이크로서비스 아키텍처는 트랜잭션을 관리하고 비즈니스 로직을 설계하는 부분이 다소 특이합니다. 하지만 사가 오케스트레이터는 아주 단순한, 일종의 상태 기계이므로 사가 프레임워크를 잘 활용하면 코드를 단순화할 수 있습니다. 물론 모놀리식 아키텍처에 비하면 트랜잭션 관리 로직이 복잡해지는 것은 어쩔 수 없지만, 더 큰 혜택을 얻으려면 작은 희생은 감수해야겠죠?