프로젝트 소개
https://github.com/Seonu-Jeong/user-exchange-manage
GitHub - Seonu-Jeong/user-exchange-manage
Contribute to Seonu-Jeong/user-exchange-manage development by creating an account on GitHub.
github.com
위 깃헙 링크를 통해 프로젝트 소개를 확인할 수 있습니다.
프로젝트 요구 사항
Lv 0. API 명세 및 ERD 작성
API 명세서 작성하기
- API 명세서는 프로젝트 최상위 경로의 README.md 에 작성
ERD 작성하기
- ERD는 프로젝트 최상위 경로에 README.md 에 첨부
SQL 작성하기
- 설치한 데이터베이스에 ERD를 따라 테이블 생성
- 최상위 경로에 테이블 작성 sql 파일 첨부
Lv 1. 고객(User)과 통화(Currency) 복잡한 연관관계
환전 요청 중간 테이블 생성
- 필드 : 고객 고유 식별자, 환전 대상 통화 식별자, 환전 전 금액, 환전 후 금액, 상태
고객과 통화 테이블 간 연관관계 설정
- 한 고객이 여러 통화로 환전할 수 있고 한 통화는 여러 고객들에 의해 환전될 수 있다.
- 환전 요청 테이블은 중간 테이블이고 User와 Currency 간 관계를 관리한다.
Lv 2. 환전 요청 CRUD
C : 환전 요청 수행
- 환전 대상 통화 식별자가 Currency 테이블에 가지고 있는 환율을 기준으로 환전을 수행한다.
R : 고객 고유 식별자를 기반으로 특정 고객이 수행한 환전 요청 조회
U : 특정 환전 요청 상태를 취소로 변경
- 상태 값은 normal, cancelled
D : 고객이 삭제될 때 해당 고객이 수행한 모든 환전 요청 삭제
Lv 3. 예외 처리
유효성 검사 추가
- 입력 값에 대한 유효성 검사를 추가하여 정책에 맞는 데이터만 취합
예외 처리 강화
- 적절한 예외 처리 로직을 추가하여 오류 발생 시 사용자에게 명확한 피드백 제동
Lv 4. PostConstruct 적용
조건
- 스프링이 구동될 때 통화 테이블에 있는 환율이 0이거나 음수이거나 지정된 범위를 벗어나는 경우
유효하지 않은 값으로 간주하고 로그를 기록
Lv 5. JPQL
JPQL을 사용하여 고객의 모든 환전 요청을 그룹화하여 조회
반환해야 하는 칼럼
- 해당 고객이 수행한 환전 요청 데이터들의 총 row 수
- 해당 고객이 환전을 요청한 총 금액
조회 예시
{
"count": 3,
"totalAmountInKrw": 50000.00
}
KPT 회고
Keep
Service 메서드를 최대한 활용하기
이전 팀 프로젝트에서 각 도메인 별로 패키지를 만들어 협업을 했었다. 프로젝트 크기가 크지는 않았지만 도메인 계층으로 나눈 이유는 깃헙 사용의 미숙함으로 충돌을 최소화 하고 싶었기 때문이다.
하지만 각 도메인 패키지마다 service, repository 가 존재했고 비슷한 기능들을 중복으로 각자 만들어서 사용하는 상황이 발생했다. 마지막에는 마감 기한이 급해서 내 도메인의 service 기능을 다른 도메인에서 사용하는 상황이 발생했다.
이번 프로젝트를 하면서 Service 클래스를 어떻게 사용해야 하는가에 고민을 했고 다음과 같은 결론을 내렸다.
- 협업 시 충돌을 두려워하지 말고 기능 중복 작성을 피하기 위해 하나의 Service 클래스를 공유해서 작성하자
- Service 클래스에서 Repository 사용은 최소화하고 최대한 다른 Service 클래스를 활용해서 기능을 구현하자
Entity에 생성에 null 고려
이전까지 Entity에 생성이 편해 @Builder등 Lombok 어노테이션을 무작정 사용했다. 하지만 Entity는 DB 테이블 객체와 연관되는 객체로 not null이 되어야 하는 제약 등이 있다. @Builder 같은 어노테이션은 제약에 맞지 않은 Entity를 생성할 가능성이 있다.
Entity 필들의 nul 제약 조건을 고려해서 생성자를 직접 만드는 것이 좋다고 생각한다.
Problem
postman api 작성의 문제점
마크다운으로 작성한 api 문서를 각 api마다 첨부 할 수 있어서 이때까지 postman api을 이용해 api 문서를 작성했다.
사실 이전 팀 프로젝트에서는 노션으로 api 문서를 작성했지만 템플릿이 불편해서 사용하지 않았다.
하지만 개인 프로젝트로 사용하는 경우라면 크게 문제되는건 없지만 협업 시 다 같이 작성하고 수정하기에는 매우 불편하다.
Try
postman api 대신 노션을 주 api 명세서 작성 툴로 사용하는 것이 장기적으로 좋을 거 같다. api 명세서를 위한 템플릿을 만들 필요가 있을 거 같다.