오케스트레이션 사가의 장단점
오케스트레이션 사가는 다음과 같은 장점이 있습니다.
• 의존 관계 단순화: 오케스트레이터는 참여자를 호출하지만 참여자는 오케스트레이터를 호출하지 않으므로 순환 의존성이 발생하지 않습니다. 즉, 오케스트레이터는 참여자에게 의존하지만 그 반대는 성립되지 않으므로 순환 의존성은 발생하지 않습니다.
• 낮은 결합도: 각 서비스는 오케스트레이터가 호출하는 API를 구현할 뿐, 사가 참여자가 발행하는 이벤트는 몰라도 됩니다.
• 관심사를 더 분리하고 비즈니스 로직을 단순화: 사가 편성 로직이 사가 오케스트레이터 한곳에만 있으므로 도메인 객체는 더 단순해지고 자신이 참여한 사가에 대해서는 알지 못합니다. 가령 Order 클래스는 사가를 모르기 때문에 상태 기계 모델은 더욱 간단해져서 주문 생성 사가 실행 도중 APPROVAL_PENDING → APPROVED로 바로 상태 전이됩니다. 또 이 클래스는 사가 단계에 대응되는 중간 상태가 하나도 없으므로 비즈니스 로직은 훨씬 단순해집니다.
오케스트레이션도 단점은 있습니다. 비즈니스 로직을 오케스트레이터에 너무 많이 중앙화하면 똑똑한 오케스트레이터 하나가 깡통 서비스에 일일이 할 일을 지시하는 모양새가 될 수도 있습니다. 이 문제는 오케스트레이터가 순서화만 담당하고 여타 비즈니스 로직은 갖고 있지 않도록 설계하면 해결됩니다.
아주 단순한 사가가 아니라면 가급적 오케스트레이션 방식을 권장합니다. 그런데 사가를 이용할 때 편성 로직보다 더 골치 아픈 이슈가 있습니다. 바로 비격리 문제입니다. 격리가 안 되면 트랜잭션을 어떻게 처리해야 할까요?