주문 서버 개발기 3편 (구현)
설계한 주문 생성 API를 implement 레이어에 구현체를 두고 모든 흐름이 비즈니스 레이어로 향하도록 구현한 과정. 정합성을 맞추는 방법은 장기 트랜잭션과 개별 트랜잭션 조합 두 갈래를 놓고 저울질하는 데서 멈춘다.
작성날짜: 24.09.30
📚 Table of Contents
해당 포스팅은 아래의 시리즈로 구성되어 있습니다. 시리즈대로 포스팅을 읽어주세요 🧑🏼🌾
지속 가능한 소프트웨어에 맞게 주문 생성 API를 구현해보자
1. 먼저 지속 가능 소프트웨어의 대략적인 구성을 살펴보자
- 최종적으로 구현체는 비즈니스 레이어로 가게끔!
2. 그렇다면 주문 생성 API는 어떻게 만들까?
이전 예측 가능하고 제어하기 쉬운 소프트웨어에 대해 알아보자 (feat. 지속 성장 가능한 소프트웨어를 만들어가는 방법) 참고해서 설계해보자!
3. 전체 구조는??
현재 핀테크 서비스, 배송 서비스 외부 연동은 할 수 없는 상황
implement layer로 구현체를 만들고 모든 구현체는 비즈니스 로직으로 향하도록 설계!
3-1. 이렇게 흐르게 된다!
이제부터는 일반적인 주문 생성 프로세스를 살펴보자
장기 트랜잭션으로 묶을수도 있고 개별 트랜잭선을 조합해서 개발을 해볼 있는 상황
- 주의할 점은. 동시성 처리, 보상 트랜잭션, 비동기 처리 등으로
데이터 정합성을 맞춰야 한다.
주요 주문생성 API 단계
- 상품 처리
- 상품 정보 확인
- 재고 확인
- 배송 처리
- 배송 정보 처리 (테이블 추가 필요)
- 결제 처리
- 결제 정보 처리
- 재고 정보 처리
- 배송 요청 (외부 택배사)
위를 토대로 본격적으로 주문 프로세스를 설계해보자
1. 먼저 대략적인 구조를 만들자
2. 각 주요 처리 부분의 상세 설계를 해보자
3. 여기에 스프링 컨테이너 프로세스를 추가해보자
4. 마지막으로 이걸 DIP도 같이 살펴보면?
최종적으로 지속 성장 가능한 코드를 만들어가는 방법 모범 사례를 참고해서 비교해보자
| 모범 사례 | 이너서클 1기 주문생성 API 예상 로직 |
|---|---|
 |  |
추가. 토스 컨퍼런스 자료 지속 성장 가능한 코드 만들어가는 방법 중 패키지 구조 개선 건
기존 component 패키지에서 좀 더 도메인을 명확히 하기 위해
domain패키지로 변경하다!
회고
- 지속 가능한 소프트웨어 설계를 위해서는 누구나 읽기 쉬운 비즈니스 규칙(유비쿼터스 언어)로 작성 해야된다는 점에서 인상깊었다.
- 단지 비즈니스 구현에 집중하는 것이 아닌 비즈니스 (도메인) 언어라는 새로운 관점에서 설계를 해보는 경험이였다.