🗺️ 핵심 설계도의 작성과 작업 흐름.

실제 진행 중인 프로젝트를 기반으로 하여 애자일(Agile)한 접근 방식으로 세 가지 설계를 해보도록 하겠습니다.

처음부터 모든 기능을 완벽하게 설계하는 대신, 가장 핵심적인 1단계(Iteration 1) 를 먼저 정의하고, 이를 바탕으로 점진적으로 확장해 나가는 방식으로 설계하겠습니다.

📌 1단계 (Iteration 1): 핵심 기능 - 주문 목록 조회 및 상태 변경

가장 먼저 필요한 최소 기능은 “들어온 주문을 확인하고, 배송 상태를 ‘결제완료’에서 ‘배송중’으로 바꾸는 것” 입니다.

• 요구사항 (MVP) :
  • 관리자는 시스템에 들어온 모든 주문의 목록을 최신순으로 조회할 수 있다.
  • 관리자는 특정 주문의 배송 상태를 변경할 수 있다. (예: 결제완료 -> 배송중)
• 시스템 아키텍처 (단순하고 명확하게) :
  • 새로운 Controller/Service 추가 :
    • 기존 아키텍처를 그대로 활용하여 OrderAdminController와 OrderService를 새로 추가합니다.
    • 복잡한 외부 시스템 연동 없이, 내부적으로 처리 가능한 간단한 CRUD 구조로 시작합니다.
  • API Endpoints 정의 :
    • GET /api/admin/orders : 전체 주문 목록 조회
    • PATCH /api/admin/orders/{orderId}/status : 특정 주문의 상태 변경
• 데이터베이스 설계 (핵심 데이터부터) :
  • 새로운 ORDERS 와 ORDER_ITEM 두 개의 테이블을 설계합니다.
    • ORDERS 테이블 : 회원(MEMBER) 이 언제 주문했는지, 현재 배송 상태는 무엇인지를 저장합니다.
    • ORDER_ITEM 테이블 : 해당 주문에 어떤 상품(PRODUCT) 이 몇 개, 얼마에 포함되었는지를 저장합니다.(ORDER와 PRODUCT의 M:N 관계를 해소하는 중간 테이블)

📌 2단계 (Iteration 2): 기능 확장 - 검색 및 상세 조회

핵심 기능이 완성되면, 이제 관리의 편의성을 높이는 기능을 추가합니다.

• 요구사항 (기능 확장) :
  • 주문 목록에서 특정 조건(주문 상태, 회원 이름, 주문 날짜 등)으로 검색하는 기능을 추가합니다.
  • 주문 목록의 각 항목을 클릭하면, 해당 주문에 포함된 상품 목록과 배송지 정보 등 상세 내역을 조회하는 기능을 추가합니다.
• 시스템 아키텍처 (기존 구조 강화) :
  • GET /api/admin/orders API가 Query Parameter 를 받을 수 있도록 확장합니다.
    • 예: ?status=SHIPPING&memberName=홍길동
  • Service 계층에 JPA의 Specification 이나 QueryDSL을 도입하여 동적 쿼리 생성 로직을 추가합니다.
• 데이터베이스 설계 (성능 최적화) :
  • 검색 조건으로 자주 사용될 ORDERS 테이블의 status, order_date 컬럼에 인덱스(Index) 를 추가하여 조회 성능을 향상시킵니다.

📋 주문 관리 요구사항 명세서.

위의 애자일 설계를 바탕으로 1단계(Iteration 1) MVP에 해당하는 요구사항 명세서를 작성해보겠습니다.

• [요구사항 명세서]
  • UC-002: 관리자 주문 관리
  • 설명: 관리자는 고객이 주문한 내역을 확인하고, 배송 상태를 관리하여 원활한 상품 배송 프로세스를 지원합니다.
• 1. 기능 요구사항 (Features)
  • OM-01: 주문 목록 조회
    • 기본 규칙:
      • 관리자는 전체 주문 목록을 조회할 수 있습니다.
      • 목록은 가장 최근에 주문된 순서(내림차순)로 정렬되어야 합니다.
      • 각 목록 항목에는 주문 ID, 주문자 이름, 주문일시, 총 주문 금액, 주문 상태가 표시되어야 합니다.
    • 예외 처리:
      • 조회할 주문이 하나도 없을 경우, 빈 목록과 함께 “주문 내역이 없습니다.”라는 메시지를 반환합니다.
  • OM-02: 주문 배송 상태 변경
    • 기본 규칙:
      • 관리자는 특정 주문의 배송 상태를 변경할 수 있습니다.
      • 변경 가능한 상태 흐름은 다음과 같습니다:
        • 결제완료 ➞ 배송준비중 ➞ 배송중 ➞ 배송완료
      • 상태 변경이 성공하면, 변경된 주문의 상세 정보를 즉시 반환합니다.
    • 예외 처리:
      • 존재하지 않는 주문 ID로 요청 시, “존재하지 않는 주문입니다.”라는 오류 메시지를 반환합니다.(HTTP 404 Not Found)
      • 이미 배송완료 또는 주문취소 된 주문의 상태를 변경하려고 할 경우, “이미 처리 완료된 주문은 상태를 변경할 수 없습니다.”라는 오류 메시지를 반환합니다.(HTTP 400 Bad Request)
      • 유효하지 않은 상태 값(예: SHIPPED 대신 SHIPPING)으로 요청 시, “유효하지 않은 주문 상태입니다.”라는 오류 메시지를 반환합니다.(HTTP 400 Bad Request)
• 2. 데이터 정책
  • 모든 주문 상태의 변경 이력(언제, 어떤 상태에서 어떤 상태로 변경되었는지)은 별도의 로그 테이블에 기록되어야 합니다.(향후 확장을 위한 정책)
  • 주문 데이터는 고객의 재주문 및 통계 분석을 위해 영구적으로 보관하는 것을 원칙으로 합니다.