Skip to content

Home

Jump to bottom
chanhyeoKingOfDev edited this page Nov 1, 2023 · 4 revisions

Team 7 Dev Docs

0. 인프라 구성

..

1. 시나리오 분석

a. useCase 정의 및 예상 IO 명세

사용자 관점 1
  • 사용자는 택시 이용을 위해 출발지/도착지 위치 정보를 설정하여 택시를 호출 할 수 있다.

    • 사용자는 로그인한 뒤 ‘택시 호출’을 누른다.

      <aside> 💡 택시 호출

      1. Title: 택시 호출
      2. Actor: 사용자
        • Precondition:
          • 로그인 된 상태
      3. I/O:

        • Input:

          변수명 타입 설명 필수
          userId Long 사용자 식별값 O
          departureLocation String 출발지(Kakao API) O
          arrivalLocation String 도착지(Kakao API) O
          taxiType ENUM 택시 종류 O
      4. Main Flow:
        • 사용자는 앱에서 택시 호출을 요청한다.
        • 출발지(GPS, 검색어), 도착지(검색어) 위치 정보를 기반으로 택시 배정을 시작한다.
        • Kakao API를 이용하여 출발지, 목적지에 대한 동선을 파악하여 예상 금액을 산정하고(Kakao API), 택시 종류와 예상 결제 금액 정보를 제공 받는다.
        • 택시 종류를 선택하고 내부 결제 시스템을 통해 결제를 진행한다.
        • 출발지에서 도착지로 이동이 가능한 택시를 배정 받는다.
        • Kakao API 예상 금액과 실제 택시 금액(택시 자체 파악 금액)이 상이한 경우(거리, 고속도로 이용료 등) 처리 방법 협의
      5. Postcondition:
        • 사용자는 택시 호출 요청에 대한 결과로 배정된 택시와 택시 기사정보를 제공받는다.
      6. Alternative Flow:
        • 현재 매칭 가능한 택시가 없는 경우 호출 실패 메시지를 보여준다.
        • 결제가 정상적으로 진행되지 않았을 경우, 호출 실패 메시지를 보여준다.
      7. Exceptions:
        • 검색어로 입력된 위치 정보가 유효하지 않은 경우
        • 모든 기사가 운행중을 경우(매칭 가능한 택시가 없는 경우)
사용자 관점 2
  • 사용자는 특정 위치정보를 즐겨찾기로 등록할 수 있다

    • 사용자는 로그인 후 ‘즐겨찾기’ 버튼을 누른다.

      <aside> 💡 즐겨찾기 등록

      1. Title: 특정 위치 즐겨찾기
      2. Actor: 사용자
        • Precondition:
          • 로그인 된 상태
      3. I/O:

        • Input:

          변수명 타입 설명 필수
          userId Long 사용자 식별값 O
          addressName(Kakao API 검색어) String 위치 정보 이름(검색어) X
          x String X 좌표값, 경위도인 경우 경도(longitude) O
          y String Y 좌표값, 경위도인 경우 위도(latitude) O
          favoriteLocation String 사용자가 설정한 위치정보 이름 X
      4. Main Flow:
        • 사용자는 앱에서 저장하고자 하는 위치 정보를 저장하기 위해 요청한다.
        • 시스템은 입력받은 위치 정보를 기반으로 위치정보를 저장한다.
      5. Postcondition:
        • 사용자는 앱에서 즐겨찾기 요청 후 요청에 대한 결과를 제공받는다.
      6. Alternative Flow:
        • 즐겨찾고자 하는 위치가 이미 있는 경우, 저장 실패 메시지를 보여준다.
      7. Exceptions:
        • 검색어로 입력된 위치 정보가 유효하지 않은 경우
        • 이미 동일한 이름의 장소가 즐겨찾기에 등록되어 있는 경우(x,y 값으로 판별)

      </aside>

사용자 관점 3
  • 사용자는 택시 이용을 위해 사전에 계좌 / 카드 정보를 등록한다.

    • 사용자는 택시 사용 결제를 위한 계좌를 등록한다.

      <aside> 💡 계좌 등록

      1. Title: 계좌 등록
      2. Actor: 사용자
        • Precondition:
          • 로그인 된 상태
      3. I/O:

        • Input:

          변수명 타입 설명 필수
          memberId Long 사용자 식별값 O
          paymentType Char 결제 타입 O
          accountNum String 계좌 번호 O
          accountHolder String 예금주 O
          accountHolderInfo String 주민등록번호 앞 7자리 O
          banKName String 은행명 O
          isDefault Boolean 기본 결제 수단 여부 O

      4. Main Flow:

        • 사용자는 결제 수단 중 카드를 선택한다.
        • 카드 번호, 유효 기간, cvc, 은행명을 입력 후 등록을 요청한다.
        • 시스템은 입력받은 정보(카드 번호, 유효 기간, cvc, 은행명)을 토대로 카드의 유효성을 확인한다.
        • 시스템은 유효성 검증이 완료된 카드 정보를 저장한다.
        • 시스템은 등록이 완료된 카드 정보를 브라우저에 전달한다.

      5. Postcondition:

        • 사용자는 등록이 완료된 카드 정보를 확인할 수 있다.

      6. Alternative Flow:

        • 유효하지 않은 카드 정보를 입력했을 경우 “유효하지 않은 카드입니다.” 라는 메시지를 반환한다.
        • 이미 등록된 카드 정보를 입력했을 경우 “이미 등록된 카드입니다.” 라는 메시지를 반환한다.

      7. Exceptions:

        • 계좌의 유효성 검사는 외부 API(대체 모듈 생성)를 통해 확인한다.
          • 해당 계좌의 유효성 검사 결과에 따라 메시지가 달라질 수 있다.
            • 카드 번호 오류
            • 카드 만료 </aside>
사용자 관점 4

  • 택시 이용이 완료되면, 사용자의 기등록된 결제 정보를 통해 결제를 진행한다.

    기사님이 해당 건에 대해 "운행 완료" 요청을 할 시에, 진행된다. 운행 완료 시 택시 운행 정보를 저장한 후 해당 사용자에게 결제 요청 API를 호출한다.

    해당 사용자에게 해당 택시 운행에 대한 결제 요청 API 가 호출된다.

    • 최종 결제 금액
    • 해당 사용자 식별자값

    • 해당 사용자의 결제 정보를 기준으로 결제한다.

      <aside> 💡 결제

      1. Title: 택시 이용 결제
      2. Actor: 사용자
        • Precondition:
          • 해당 택시 운행 건의 상태가 “운행 완료” 이다. (운행 기록)
          • 사용자의 결제 정보가 등록 되어있다.
      3. I/O:

        • Input:

          변수명 타입 설명 필수
          memberId Long 사용자 식별값 O
          drivingRecordId Long 운행 기록 식별값 O
          fare Long 택시 이용 요금(결제 금액) O
      4. Main Flow:
        • 택시 이용에 대한 결제를 진행 중 결제 오류가 발생했을 경우 현장 결제를 진행한다.
        • 기사는 현장 결제(실제) 완료 후 현장 결제를 선택(호출) 한다.
        • 시스템은 해당 운행 건의 상태를 “결제 완료”로 변경한다. (운행 기록)
        • 시스템은 기사의 운행 상태를 대기중으로 변경한다.
      5. Postcondition:
        • X
      6. Alternative Flow:
        • X
      7. Exceptions:
        • X
사용자 관점 5

  • 사용자는 본인의 택시 이용 기록을 확인할 수 있다.

    택시 이용 기록에는 아래와 같은 정보가 포함된다.

    • 호출 일시, 운행 시간
    • 출/도 정보
    • 탑승한 택시 정보

    • 사용자가 자신의 택시 이용 기록을 조회한다.

      <aside> 💡 택시 이용 기록 조회

      1. Title: 택시 이용 기록 조회
      2. Actor: 사용자
        • Precondition:
          • 로그인 된 상태
          • 택시 이용 기록이 한 건 이상
      3. I/O:

        • Input:

          변수명 타입 설명 필수
          userId Long 사용자 식별값 O
          startDate String 조회 시작 일자 O
          endDate String 조회 종료 일자 O
          page Int 페이지 번호 O
          perPage Int 페이지 당 결과 수 O
      4. Main Flow:
        • 사용자는 택시 이용 기록을 조회한다.
          • 조회 시작/종료 일자를 선택한다.
          • 페이지 당 보여줄 기록의 개수를 선택한다.
        • 시스템은 전달 받은 조회 시점을 토대로 택시 이용 기록을 조회하여 반환한다.
      5. Postcondition:
        • 사용자는 택시 이용 기록에 대한 정보를 확인할 수 있다.
      6. Alternative Flow:
        • 해당 시점에 택시 이용 기록이 없을 경우 “이용 기록이 없습니다.” 메시지를 반환한다.
      7. Exceptions:
        • X </aside>

b. 유스케이스 다이어그램 및 요구사항 분석

2. TDD

a. Rule

(1) 3계층의 요소 각각의 테스트를 독립적으로 할 때에는 일대일 추상화보단 Mock을 이용해 작업 비용을 낮춘다.

(2) 테스트는 innerClass를 이용해 상위 분류를 지정해 유사한 테스트는 묶어서 진행한다.

(3) 실제 비즈니스 로직이 들어갈 command는 최대한 POJO스럽게 작성해 비즈니스 핵심 로직에 대한 testability를 높인다.

(4) 테스트 케이스의 이름은 displayName 대신에 테스트 케이스 이름 예시() 와 같이 메서드 이름을 통해 표현한다

fun `택시기사님은 영업 참여를 위해 택시 정보를 등록한다`() { .. }      /* 테스트 케이스 이름 표현 방식 제안 */

b. 개발 과정에서 염두할 것

(1) 테스트를 작성이 마무리 됐을 때 개발이 끝나는 개발 생명주기를 경험하는 것을 목표로 할 것

(2) 해당 코드에 테스트가 왜 필요한지 고민하면서 개발할 것



3. 로그백 정책

a. 로깅 대상

대상 로깅 형태 식별 구분
method call [시간] [호출 메서드 명] call {traceId}
parameter [시간] [파라미터 값] {traceId}
exception [시간] {예외 메시지} {stack trace} {traceId}
sql query [시간] {쿼리 내용} {traceId}
  • 식별 불가 고객: anonymous 처리

b. 개발 환경 별 로그 레벨

환경 로깅 정책
dev DEBUG
prod PROD

c. 로그 압축 기준

(1) 생성된지 이틀이 지난 건에 대해 (2) 용량이 100MB가 넘어간 건에 대해

d. 로그 삭제 기간

미정


Clone this wiki locally