f-lab-edu / in-bob-we-trust Goto Github PK

Type : Feature

구현한 클래스들의 전체적인 구조는 "#3 신규주문 수신기능"과 동일합니다.

Use Case 참고

• 사장님은 접수요청 받은 주문에 배달대행사, 픽업시간 등을 정해서 주문 접수를 승인합니다
• 사장님은 사정이 있어서 주문 접수를 거절합니다.

Steps

Domain > Controller > Service > Repository

Tasks 목록

• Gradle Build 스크립트 수정
• Jacoco 추가

Description 상세

Gradle Build 스크립트 수정

• 그레이들 라이프사이클의 other로 포함되어있던 integrationTest 를 verification 프로세스로 이동시킵니다.
• 각 모듈별 빌드 아웃풋을 ${rootProjectDir}/build/{모듈명}으로 이동시킵니다.
• Intellij의 idea plugin 을 추가해서 integrationTest 디렉토리를 실질적인 test 디렉토리(녹색)로 인식하도록 설정합니다.

Jacoco 추가

• 테스트 커버리지 관리를 Gradle 태스크 레벨에서 실행하려고 합니다. 커버리지 외의 부분들만 SonarQube 해결할 예정입니다.
• 라인 커버리지로 적용할 예정입니다.
• Unit 테스트와 integrationTest 에 모두 적용합니다.

Type : Feature

Description

• 주문완료 이후 주문서버에서 주문정보를 수신받는 기능 추가
• *** 코드 리뷰 후 도메인 적용 필요

Description

• 배달정보조회 기능을 추가합니다.
• 배달정보가 필요한 경우는 다음과 같습니다.
  • 다른 배민서비스
  • 사장님 배달현황체크
  • 고객님의 주문조회

Features

• GET /api/delivery
  • queryParam으로 page와 size를 전달하며 페이징
• GET /api/delivery/{id}
  • 배달정보의 ID로 조회

Description

• "Issue #3 신규주문 수신 기능" 에서 파생되는 기능입니다.
• 신규주문 수신이 완료되면 사장님 어플리케이션에 push 방식으로 HTTP 요청을 전송합니다.

Description

• 프로젝트 목적 소개
• 프로젝트 설명

Description

• PR #4 에서 생성된 엔티티 패키지 오타 먼저 바로잡습니다.

Description

• 라이더배정 이후에 라이더님이 생성하는 픽업완료 -> 이동(배달) -> 배달완료 이벤트들을 수신하는 기능을 구현합니다.
• Validation 요구사항은 프로젝트 위키 > Business Rules > Validation 목록에서 확인 가능합니다.

Tasks

• 배달상태 -> 픽업완료
• 배달상태 -> 배달완료

설명

• 서비스에 필요한 데이터를 설계 (ERD작성)
• Entity (자바클래스) 작성
• 데이터베이스 설정
• 데이터베이스에 DDL 반영하기

@ak2j38 위 몇개는 어제 보여주신 것들 그대로 반영하면 되겠네요

Expected

• 배달대행사에서 라이더배정 요청 Endpoint
• 라이더 배정을 위한 Validation
• 배달상태 업데이트

Description

• Integration 테스트를 추가합니다.
• Delivery 클래스의 시간과 배달상태의 모든 경우의 수를 테스트하며 서비스 레이어의 Validation 체크

프로젝트의 뼈대작업

Gradle 의 멀티모듈 전략 적용

• 사장님 고객님 배달대행사 그리고 중계서버 를 모듈단위로 적절히 분리하여 늘어나는 컴포넌트에 대비합니다.

Lean 한 빌드파일

• build.gradle 파일을 작성시에 반드시 필요한 부분들만으로 구성해야합니다.

Description

• Issue #38 의 sub-issue
• 주문과 관련된 *mapper.xml 를 작성합니다.
• 엔티티 Order와 연관됩니다.

Description

• URI : GET /delivery/status/{orderid}

Description

요청과 접수기능 분리
기존에는 배달관련 정보들을 수집하는 기능과 사장님, 배달대행사 등으로 요청을 전송하는 클라이언트 기능을 order-server 에서 함께 구현했습니다.

위 두가지 기능을 다음과 같이 분리합니다.

delivery-info-service

• 배달 관련 정보들을 수집하는 역할
• EX) 신규주문접수 / 배달상태 업데이트 / 라이더배정

delivery-relay-service

• 배달액션을 요청을 전송하는 역할
• EX) 사장님에게 - 주문접수요청 / 배달대행사에게 - 라이더배정요청

Tasks

• 기존 모듈 이름 변경 order-server >>> delivery-info-service
  • resolved by #109
• 새 모듈 delivery-relay-service 생성
  • resolved by #111

Additional Features

• #112

Overview

• 팀 구성의 변경으로 동기(sync) 구조에서 비동기(async)로 전환을 시작하게 되었습니다.
• 기존 동기, 스프링부트 기반의 구조에서 스프링 웹플럭스를 활용한 비동기 형식의 구조로 변환합니다.

Tasks

• 디펜던시 클린업
• 소스코드 클린업

Description

• Issue #38 의 sub-issue
• 라이더 위치와 관련된 *mapper.xml 를 작성합니다.
• 엔티티 RiderLocation와 연관됩니다.

Description

• Github Actions 기본 스크립트 작성
• 코드포맷팅 자동 적용
• Push, PR시 자동 Gradle build test 실행

Description

• Issue #28 에서 적용했던 springfox 대신 springdoc-openapi-webflux-ui로 디펜던시를 변경했습니다.
• 내부적으로 사용시 어노테이션 이름만 다를뿐 거의 동일하지만 SpringWebflux 지원여부 차이가 있습니다.

Overview

• 고객님의 주문완료 이후 중계서비스로 중계를 요청하는 기능입니다.

Description

• API 엔드포인트를 통해 배달관련 정보를 수신합니다.
  • (resolved in PR #89 )
• 데이터베이스에 저장합니다.
  • (resolved in PR #90 )
• 사장님에게 주문접수 요청하기(다음기능)를 트리거합니다.
  • (resolved in PR #92 )

Description

• 주문상태 enum OrderStatus에 필요한 로직들 추가
• #61 를 위한 셋업

Changes

• getNext() 주문상태의 다음상태 리턴, 마지막 값은 에러
• getInitial() 신규주문에 대한 초기상태 리턴
• returnSomethingElse() 테스트를 위한 현재상태 외의 다른 상태를 리턴

• 작업 목록
  • 도메인 목록에 대한 mapper.java 파일 작성
  • repository interface 파일 작성
  • DB 연결 관련 테스트 파일 작성

Description

• #39 의 연장
• #39 에서 수정된 entity 를 바탕으로 ERD를 작성
• #39 에서 수정된 entity 를 바탕으로 DDL 수정

Description

• #31 의 작업 시작전 점검

Tasks

• testRuntime 을 위한 H2 database 설정 file & MySQL 모드
• 커넥션 테스트
• initial data 설정
• mybatis 매퍼 관련 설정 적용
• 테스트용 Sample 매퍼 작성

Description

mybatis 매퍼설정

• 본격적인 Mapper 작성 이전에 실행 여부 확인을 위한 간단한 테스트작성

H2 database 설정

• H2 database 는 mem, file, embedded, server 모드 존재
• 가장 간단한 in-memory db 적용

Overview

• #87 에서 구현한 사장님에게 주문접수 요청하기 이후의 기능입니다.
• 서비스 플로우는 사장님 주문접수완료 -> 배달대행사 라이더배정 요청 의 요청순으로 이어집니다.

Description

• 사장님의 주문접수완료 요청을 받습니다.
• 사장님의 주문접수완료 정보의 유효성 검사 후 데이터베이스에 저장합니다.
• 배달대행사에게 라이더배정 요청을 전송합니다.

Description

• 로깅 기능을 추가합니다.
• 현시점까지 적용대상 포인트들은 다음과 같습니다.
  • mybatis 변수 적용된 쿼리, mybatis 쿼리 결과
  • request와 response

Tasks

• 값의 유효성 검사가 필요한 부분들 찾아내기

Descriptions

• 유효성검사 전략 : Validation 적용 설명
• 유효성검사 목록 : Use Case

Description

• "Issue #6 사장님 주문접수완료" 에서 파생되는 기능입니다.
• 사장님이 주문접수완료 이후 배달대행사 어플리케이션에 push 방식으로 HTTP 요청을 전송합니다.

Description

• Issue #38 의 sub-issue
• 라이더와 관련된 *mapper.xml 를 작성합니다.

Tasks

• 보안이 필요한 부분들을 생각하기
• 보안 적용 전략 찾아보기
• 적용하기

Notes

적용 대상 기능들... (예상)

• 배민주문서버 : 다른배민서비스(ex. 주문서버)와의 안정적인 통신
• 고객 : 고객이 요청하는 주문 정보가 고객 본인의 주문 확인
• 라이더 : 라이더(외부)와의 안전한 통신
• 사장님 : 사장님(외부)과의 안전한 통신
• 배달대행사 : 배달대행사(외부)와의 안전한 통신

Description

• 목적이 명확하지 않은 Util 과 Common 컴포넌트를 수정하기

적용대상

• ApiUtil
• Common 패키지
  • CommonResponseHandler
  • CommonExceptionHandler

Description

• 처음 동기(Sync) 방식 기능구현 단계입니다.
• PR과 Issue 들이 쌓이는 것을 막기 위해 Parent Issue 와 Parent PR 을 만들겠습니다.
• 사전에 작성한 유즈케이스를 참고하고 있습니다.

Included Features

• Issue : #3 사장님 주문접수완료
• Issue : #6 신규주문 수신 기능
• 라이더 배정 API
• 라이더 배달상태Update
  • 라이더 픽업완료 API
  • 라이더 위치확인 API
  • 라이더 배달완료 API
• 주문상태확인 API

Description

• Issue #38 의 sub-issue
• 주문과 관련된 *mapper.xml 를 작성합니다.
• 엔티티 Delivery와 연관됩니다.

Tasks

• Exception Handling 전략 세우기
• 프로덕션 코드에 반영
• 테스트 업데이트

Description

• #29 resolved
• 프로젝트 전반에서 발생하는(or 시키는) Exception들을 횡단관심사(cross-cutting concern) 으로 분류하고 스프링에서 제공하는 @ControllerAdvice 를 활용해서 일관성있게 처리한다.

적용대상 클래스

1. CommonExceptionHandler

• @ControllerAdvice 적용 대상
• 메소드에 적용된 @ExceptionHandler 어노테이션에서 명시된 XXXException.class 발생시 ApiUtil 를 활용해서 메시지가 담긴 응답으로 변환

2. 모든 Controller

• ApiUtil 클래스 의 successResponse 또는 errorResponse 메소드를 활용해서 ResponseEntity<ApiResult<T>> 생성.

3. ApiResult

• 유의미한 응답을 담는 목적을 가진 클래스
• 필드
  • success : boolean (요청 성공 여부)
  • body : T (요청 성공시의 데이터)
  • error : ApiError (에러 발생시 Http 상태코드와 서버에서 지정한 에러메시지 리턴 )
• 예시)

{
  "success": true,
  "body": {
    "orderId": "order-1237892191",
    "shopId": "shop-2374057109"
  },
  "error": null
}
{
  "success": false,
  "body": null,
  "error": {
    "message": "ill arege exception message....",
    "status": 400
  }
}

Description

• Functional 과 Integration 테스트로 분개합니다.
• Github Action를 통해 위 테스트 전략을 CI 프로세스에 자동화합니다.

Tasks

• Functional-Integration 테스트 분리전략 리서치
• 프로젝트 적용 계획
• 다른 git repo 에서 깃허브 액션 적용 테스트
• 반영
• local 테스트
• 기존 actions 테스트 Job의 build 태스크 삭제

Description

• async 전환에 필요한 디펜던시들을 추가합니다.
• 스프링 웹플럭스를 활용한 async/reactive 서버 디펜던시들을 추가합니다.

Type : Feature

Feature 1 : (사장님) 주문접수요청 전송

• resolves #19
• #3 에서 파생되는 기능
• 주요 메소드 OrderProducer.sendNewOrderMessage()
• 신규주문 수신 후 사장님에게 요청을 전송합니다.

Feature 2 : (배달대행사) 배차요청 전송

• resolves #20
• #6 에서 파생되는 기능
• 주요 메소드 DeliveryProducer.sendAddDelieryMessage()
• 주문접수완료 후 배달대행사 요청 전송

Description

• Issue #42 와 Issue #39 의 후속편
• PR #27 이전에 임시로 적용했던 model.vo 패키지의 클래스들을 전부 model.entity 패키지의 클래스로 대체하는 작업

Tasks

• 위 내용을 바탕으로 DTO 클래스 생성 등 한두개로 분류, 또는 model로 통일 클래스 네임 변경
• 적용가능 best practice 또는 라이브러리 비교분석
• MapStruct 적용

Sub-Issues

• #70
• #71
• #72
• #73
• #74
• #75
• #76

References

• https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
• https://oingdaddy.tistory.com/350

진행상황

• #30 해결 이후로 변경. REST API 리턴 타입에 대한 어느정도의 기준이 필요하기때문에

Tasks

• 고려사항 짚어보기
• 플러그인 선정
• 프로젝트에 적용 (기존 REST API 코드)

Description

• REST 도큐먼트 툴이 필요한 일반적인 이유들은 생략하겠습니다.
• 중계서비스의 특성상 사장님, 배달대행사, 고객님, 다른 배민서비스 등 여러 개발팀에서 참고해야하므로 필요성이 증가합니다.

Considerations (고려사항)

1. 편의를 위해 프로덕션 코드에 얼마나 많은 문서화 코드를 포함할 각오가 되어있는가?
2. (팀 내에서 정한 최소한의 기준에 부합하는) 검증된 API 문서만 보여줄 것인가?
3. UI 에서 테스트가 가능한가?
4. 최대한의 자동화가 가능한가?

후보군

• swagger-ui
• Spring Rest docs

Reference

• https://techblog.woowahan.com/2597/
• https://taetaetae.github.io/posts/a-combination-of-swagger-and-spring-restdocs/
• https://github.com/ePages-de/restdocs-api-spec