🛒 Backend Engineering · 2/9 · 약 7분

Backend Engineering 시리즈 전체 보기

주문 상태를 몇 개의 문자열로 저장하면 정상 흐름은 빠르게 만들 수 있다. 하지만 취소와 완료가 겹치거나 이미 끝난 주문에 늦은 사건이 도착하면 상태 이름만으로는 무엇을 허용해야 하는지 판단할 수 없다.

가상의 주문 흐름을 전이 표로 다시 그려 보았다. 상태 목록보다 현재 상태, 들어온 사건, 전제 조건, 다음 상태, 후속 효과를 먼저 적자 중복과 순서 역전을 처리할 기준이 드러났다.

#Backend · #StateMachine · #DomainModel · #Reliability

이 글에서 다룰 것

• 상태 이름보다 전이 규칙을 먼저 정의해야 하는 이유
• 종료 상태와 늦게 도착한 사건을 안전하게 다루는 방법
• 전이와 후속 효과를 분리해 복구 가능성을 높이는 기준

1. 상태 목록은 허용 규칙을 말해 주지 않는다

준비, 처리 중, 완료, 취소라는 이름만으로는 완료 뒤 취소를 허용할지 알 수 없다. 같은 완료 사건이 다시 왔을 때 기존 결과를 돌려줄지 오류로 볼지도 정할 수 없다.

상태 머신의 핵심은 상태가 아니라 전이 계약이다. 현재 상태와 사건만 보지 말고 필요한 조건, 다음 상태, 기록할 이유, 발생시킬 후속 효과까지 한 줄로 정의한다.

• 현재 상태: 사건을 받기 전의 사실이다.
• 사건: 바뀌기를 요청하는 입력이다.
• 전제 조건: 전이를 허용할 판단 기준이다.
• 결과: 다음 상태와 외부에 돌려줄 응답이다.
• 후속 효과: 알림이나 재고 반영처럼 별도로 실행할 일이다.

2. 종료 상태는 결과를 되돌리지 않는 경계다

가상의 주문에서 준비 상태는 처리 시작 사건을 받을 수 있지만 완료 사건을 곧바로 받지는 않는다. 처리 중 상태는 완료 또는 취소로 이동하고, 완료와 취소는 다시 진행 중으로 돌아가지 않는 종료 상태가 된다.