백엔드
도메인 Error를 다루는 고민과 Arrow의 Either
두줄요약
결제 도메인의 오류 처리를 위해 sealed class를 검토한 뒤 Arrow의 Either를 도입한 과정을 정리했습니다. 트랜잭션, 캐시, 예외 처리와의 충돌을 피하기 위해 계층별 경계도 함께 설계했습니다.
문제 상황
- 결제 도메인에서 다양한 오류 상황을 일관되게 표현할 방식 필요
- sealed class 기반 결과 모델은 분기 예측성은 높였지만, 반복 선언과 중첩 분기로 가독성 저하
- 트랜잭션, 캐시, 프레임워크 예외 처리와 결합되며 경계 설정 문제 발생
해결 방법
- Arrow의 Either로 성공과 실패를 분리한 Typed Error 처리 도입
- 도메인과 서비스 계층에서 Either를 사용하고, 인프라 계층은 예외를 그대로 전파
- @Transactional, @Cacheable, @ControllerAdvice와 충돌하지 않도록 예외 변환 지점 분리
성능/운영 포인트
- 도메인별 Result 타입 반복 감소로 보일러플레이트 축소
- Konsist로 Either 사용 계층을 CI에서 검증
- 직렬화 부담과 도메인 침투를 피하기 위해 Either 사용 범위 제한