← 홈으로 PROJECT DECK — 01 / 06
01 · Backend · Domain Design 2025.08 — 2026.06

출고 파이프라인,
코어 도메인을 처음부터.

주문 접수부터 할당 · 분할 · 검수 · 출고 완료까지 — 존재하지 않던 핵심 파이프라인을 백지에서 설계 · 구축하고, 상태 전이 정책으로 성숙시켰습니다.

← → 방향키 · 휠 · 스와이프로 넘겨보세요

두 번의 문제

처음엔 아무것도 없어서 문제였고, 나중엔 커져서 문제였습니다.

PHASE 01 — 구축기

파이프라인이 존재하지 않았다

주문을 출고 단위(Shipment)로 어떻게 쪼갤지, 재고를 어떻게 잠글지, 취소가 오면 어디까지 되돌릴지 — 전부 백지에서 정의해야 했습니다.

PHASE 02 — 성장기

상태가 암묵적으로 변한다

주문 · 출하 · 배치의 상태가 여러 UseCase에서 각자 변경되면서, 기능이 늘수록 상태 불일치 버그가 늘어나는 구조가 됐습니다.

판단"돌아가는 파이프라인"을 넘어 "믿을 수 있는 파이프라인"으로 — 상태 변경을 전부 명시적 정책 아래로 모아야 한다.

무엇을 지었나

주문 하나가 창고를 통과하는 전 구간 — 각 단계의 도메인 규칙을 직접 설계했습니다.

주문 접수 → 재고 할당
자동 · 수동 · 취소 복원 → 출고 분할
배송방식 · 최대합포장수량 → 검수
리빈 · 결품 처리 → 출고 완료
ShipmentProcessingContext
반복 조회를 한 번에 — 처리 로직과 데이터 적재 분리
분할기 고립
합포장 정책 변경이 분할기 내부에서 끝나도록
취소 2경로
즉시 취소 / 취소 대기 → 확정 + 재고 복원 독립

다섯 가지 설계 결정

D1처리 컨텍스트 도입
출고요청 전반의 반복 조회를 컨텍스트로 묶어 — 기능 추가가 컨텍스트 확장으로 수렴.
D2분할 규칙은 도메인 서비스로
배송방식 · 최대합포장수량 분할을 고립 — 정책 변경의 파급을 차단.
D3상태 전이를 정책으로 명시 (P1)
허용 전이를 선언하고 모든 변경이 정책을 통과하게 강제. stale 보정까지.
D4UseCase 책임 분리
비대해진 UseCase를 3-way 분리, 검수 흐름도 함수 단위로 — 교차 시나리오 충돌 제거.
D5취소는 어디서든 안전하게
즉시 취소와 취소 대기 → 확정 경로 분리, 재고 복원 독립 — 시스템의 성질로.

결과 — 전부 실측입니다

23개
출고 도메인 REST API (전체 358개 중)
300+
이 축의 개인 커밋 (검수만 170)
25건
정책 도입 후 취소·결품·검수 QA 집중 해소

상태 전이 정책 도입 이후, 버그가 "어디서든 터지는 것"에서 "정책 위반으로 드러나는 것"으로 바뀌었습니다 — QA 이슈를 한 스프린트에 몰아서 닫을 수 있었던 이유입니다.

다음 프로젝트 — 성능 · 안정성 → 홈으로