피드로 돌아가기
Dev.toBackend
원문 읽기
Binary Error 모델 탈피를 통한 Compiler 수준의 Domain Outcome 강제화
Five Ways to Fail a Transport
AI 요약
Context
기존의 Result 타입이나 Try/Catch 기반 Binary Split 구조는 성공과 실패를 두 개의 버킷으로만 분리하여 도메인의 복잡성을 반영하지 못함. 이로 인해 새로운 Failure Mode 추가 시 일부 호출부에서 런타임 에러가 발생하거나, 다중 성공 경로(Multiple Success Paths)를 처리하기 위해 불필요한 중첩 레이어를 설계하는 한계가 존재함.
Technical Solution
- Ok/Error의 이분법적 구조를 제거하고 모든 도메인 결과를 동등한 지위의 Peer-level Outcomes로 정의하는 선언적 구조 도입
- 컴파일러가 모든 결과 케이스의 처리를 강제하는 Exhaustive Handling을 통해 신규 Outcome 추가 시 컴파일 에러를 유발하여 누락 방지
- Ad-hoc한 매개변수 명명법 대신 Parameter Roles를 도입하여 데이터의 역할(Payload, From, To 등)을 구조적으로 정의
- 도메인 액션과 단순 변환 함수(Transformation)를 구분하여- let 함수와 op 선언을 분리하는 설계 원칙 적용
- Type-level View인 Projections를 통해 연산별 데이터 접근 권한을 런타임 필터가 아닌 타입 시스템 수준에서 제어
- Typestate 패턴을 적용하여 엔티티의 상태에 따라 실행 가능한 연산을 컴파일 타임에 제한하는 가드 레일 구축
실천 포인트
- API 설계 시 '성공'의 정의가 단일한지, 혹은 비즈니스적으로 구분되는 다중 성공 경로가 존재하는지 검토 - 에러 핸들링 시 Generic한 Catch-all 구문 사용을 지양하고, 모든 Failure Mode를 명시적으로 열거하는 구조 채택 - 매개변수의 이름보다 '역할'에 집중하여 시스템 전반에 일관된 Parameter Role 컨벤션 적용 여부 확인 - 도메인 상태 변화에 따른 제약 사항을 런타임 If문이 아닌 타입 시스템(Sealed Class, Union Type 등)으로 표현 가능한지 분석