신발 주문 시스템 분석 ‐ 도메인 : Order - KEEMSY/shoes-ordering-system GitHub Wiki
상태: 완료
날짜: 2023-08-10 ~ 2023-08-27
결정자: KEEMSY
Context | Decision | Consequence | 개선해야 할 사항
지난 신발 주문 시스템 분석 - 도메인 에서 식별한 Order도메인에 기능적 요구사항은 다음과 같았다.
-
주문 배치: 사용자가 장바구니에 제품을 추가하고 주문 할 수 있다.(여러 상품을 주문 함께 주문할 수 있다.) -
주문 추적: 사용자는 주문 상태를 추적할 수 있다. -
주문내역: 사용자별 주문 내역을 저장 및 표시한다.
분석한 요구사항과 민첩성 과 유연성 핵심으로 개발을 진행한다.
- 지난 도메인 개발 경험 상 기능오류 및 수정이 빈번하게 일어나므로, 쉽게 변경할 수 있어야한다.
추가적으로, Product 도메인 개발이 완료되고, 최종 결정된 패키지 구조는 다음과 같다.
-
패키지 구조:
Adapater,Domain└── specific-domain ├── adapter │ ├── in │ │ └── controller │ │ ├── exception │ │ └── rest │ └── out │ ├── dataaccess │ │ ├── adapter │ │ ├── entity │ │ ├── mapper │ │ └── respository │ │ └── impl │ └── messaging │ ├── mapper │ └── publisher └── domain ├── application │ ├── ApplicationServiceImpl.java │ ├── QueryServiceImpl.java │ ├── config │ ├── dto │ │ ├── DTOException.java │ │ ├── create │ │ ├── track │ │ └── update │ ├── handler │ ├── helper │ ├── mapper │ └── ports │ ├── input │ │ ├─── service │ │ │ ├── ApplicationService.java │ │ │ └── QueryService.java │ │ └── message │ │ └── listener │ └── output │ ├── message │ │ └── publisher │ └── repository │ └── Repository.java └── core ├── DomainService.java ├── DomainServiceImpl.java ├── entity ├── event ├── exception └── valueobject
Decision 내용을 바탕으로 개발된 내용은 다음과 같다.
주문 배치: 사용자가 장바구니에 제품을 추가하고 주문 할 수 있다.(여러 상품을 주문 함께 주문할 수 있다.)
OrderItem 리스트 필드(items)를 통해 여러 상품을 함께 주문 할 수 있도록 개발하였다.
주문 추적: 사용자는 주문 상태를 추적할 수 있다.
trackOrder() 기능을 통해 주문 상태를 추적할 수 있다.
주문내역: 사용자별 주문 내역을 저장 및 표시한다.
createOrder() 을 통한 주문 생성 및 저장하며, trackOrder() 를 통해 주문을 표시한다.
PR Link: Feature/order domain #12
요구사항을 구현하기 위해 다음과 같이 설계하고 구현하였다.
Core
- Entity: Order, OrderItem
- Event: OrderCreatedEvent, OrderCancelledEvent, OrderPaidEvent
- ValueObject: OrderId, OrderItemId, OrderStatus, TrackingId
Order 엔터티 비즈니스 규칙
- price 는 0보다 작을 수 없으며, OrderItem의 가격과 수량의 합과 같아야한다.
- pay(결제) 는 PENDING 상태에서만 가능하며, 결제를 의미한다. PENDING -> PAID 로 상태를 변경한다.
- approve(승인) 는 PAID(결제완료) 상태에서만 가능하며, 주문이 승인 됨을 의미한다.
- cancel(취소) 는 상태에 따라 initCancel, cancel 으로 다르게 처리한다.
- initCancel: PAID(결제완료) 상태에서만 가능하며, PAID -> CANCELLING 으로 상태를 변경한다.
- cancel: CANCELLING 혹은 PENDING 상태에서만 가능하며, 주문을 취소한다. CANCELLING 혹은 PENDING -> CANCELLED 로 상태를 변경한다.
Application
PR Link: Feature/order application #13
식별 및 개발한 유스케이스는 2개이며, 각 특성에 따라 Command, Query 로 구분하여 서비스로 개발하였다.
- CommandService: 주문 생성
- QueryService: 주문 조회
PR Link: Feature/order adapter: Web #20
요청의 특성에 따라 CommandController 와 QueryController 로 구분하였다.
- CommandController: 주문 생성
- QueryController: 주문 조회
PR Link: Feature/order adapter: DataAccess #19
주문을 조회하는 과정에서 1:N 관계의 items 를 한번에 가져오기 위해 Fetch Join 을 사용하기 위해 Querydsl 을 추가하였다.
- JPA: 기본적인 CRUD 및 간단한 쿼리에 사용한다.
- QueryDsl: 쿼리를 직접 작성해야하는 경우 사용
PR Link: Feature/order adapter: Messaging #18
카프카를 사용하기 위한 Avro 모델 생성을 위해 다음 .avsc 파일을 추가하고 Cosumer, Producer 를 개발했다.
- Cosumer: PaymentResponseKafkaListener
- Producer: CreateOrderKafkaMessagePublisher, CancelOrderKafkaMessagePublisher
1차 개발을 진행하며, 개선 및 추가 개발 좋을 부분 및 이슈사항을 정리하면 다음과 같다.
누락된 기능
개발 간 누락된 부분이 존재하며, 해당 부분에 대한 개발이 필요하다.
주문 조회기능의 개선
현재 주문 조회는 단일 건 주문 조회 기능만이 존재한다. 하지만 이외에도 주문을 조회할 수 있는 요구사항은 다양할 수 있다.
- 고려사항: 기간 별 주문 조회, 상태에 따른 주문조회, 전체 주문 조회
한정 상품 관련 주문 특이사항 추가
주문이 급격하게 늘어나는 상황을 고민해 본다면, 한정판 상품 구매(혹은 응모)를 이야기 할 수 있으며, 이는 일반 주문하고는 차이점이 존재한다.
- 구매 조건이 제한된다.(1인 1구매 제한 등)
실제 서비스를 고려한 개발 환경 구성
현 프로젝트를 보았을 때, 실제 서비스에서는 어울리지 않는 구성 요소 및 추가하면 좋을 요소가 존재한다.
- 사용하는 DB 를 변경한다.(H2 -> MySQL Or Postgres)
- 정적 분석 도구를 추가한다.