bankingService

기술스택

• Spring Boot 2.7.8
• Java 11
• MySQL 8
• Spring Data JPA
• JUnit5

코드 컨벤션

• 구글 자바 컨벤션 가이드
• 변수/함수 이름 Camel Case
• 변수/함수의 첫 글자 소문자
• 함수 명명 : 동사 + 명사
• 주석 최소화

유스 케이스

• 사용자는 뱅킹서비스를 이용하기 위해 회원가입을 할 수 있다.
• 사용자는 계좌 잔액을 확인하기 위해 본인의 계좌 상태를 확인할 수 있다.(1인 1계좌 가정)
• 사용자는 다른 사용자를 친구로 추가할 수 있다.
• 사용자는 본인이 추가한 친구 목록을 조회할 수 있다.
• 사용자는 본인의 친구에게 돈을 송금할 수 있다.

API 목록

• 회원가입 API
• 계좌조회 API
• 친구추가 API
• 친구목록조회 API
• 송금하기 API

DB 설계

wiki 참조. https://github.com/GangBean/bankingService/wiki

주요 설계 내용

1. API 설계 원칙
   1. 웹 서비스의 api 스펙을 어떤 규칙에 따라 정의할 것인지..? 잘 설계된 API는 불필요한 커뮤니케이션을 줄여준다. -> 아키텍처를 따라 결정하는 것이 좋다.
   2. 직렬화 포맷 : 통신에 사용되는 데이터를 어떤 방식으로 표현할 지 결정해두어야 통신간(클라이언트<-> 서버) 혼란을 줄일수 있다.
   3. 웹 MVC 기반 애플리케이션을 효과적으로 구현할 수 있는 대표적인 API 아키텍처엔 무엇이 있는가?
      1. HTTP > REST
      2. GraphQL
      3. RPC
   4. 조사해본 결과 아래와 같은 이유로 REST 기반으로 API를 설계하기로 결정했다.
      1. GraphQL과 gRPC는 새로 익히는 시간이 필요하다. 그러나 두 기술의 러닝커브가 REST에 비해 높을것으로 보여 다른 API 기술을 익혀 개발을 진행하는것 보단 익숙하고 사용해보았던 REST를 조금 더 엄격하게 적용해보는 것이 더 도움된다고 판단했다.
      2. 만들고자하는 프로젝트에 필수적 기능들이 다양한 클라이언트에서 많은수의 데이터필드들을 사용하는 기능들이 아니기때문에 GraphGL이 REST에 비해 갖는 이점인 유연성이 큰 이점을 갖기 어려워 보임.
      3. gRPC는 일반적인 브라우저에서는 지원하지 않고 gRPC-Web이라는 별도의 브라우저 호환 솔루션이 필요하기 때문에 적용했을때 발생할 많은 오류들에 대한 디버깅이 쉽지 않을것으로 예상함.
2. 비즈니스 설계 내용
   1. 계좌의 잔액은 한국 통화 기준인 원 으로 정한다. 소수점은 허용하지 않고, 계산시 발생하는 원 미만금액은 모두 절사하는 것으로 정한다.
3. TDD 기반 프로젝트 개발 진행
   1. 개발 중 겪을수 있는 문제점
      1. 설계의 불확실성 : 처음으로 마주하는 주제인 경우 진행한 설계가 정상적인 상황인지 판단하기가 어려운 경우가 있었고, 초기엔 옳은 설계라고 생각하고 넘어간경우라도 이후 설계상 오류를 발견한 적이 종종 있었다. 이러한 경우 초기 설계부터 다시 시작해야하기에 처음으로 되돌아가 다시 작업해야하는 경우도 있었다.
      2. 코드 수정시 영향도분석과 재테스팅 : 코드를 수정할때 기존 기능에 대한 영향도 분석은 필수이다. 프로젝트가 커질수록 코드에 연관된 기능들이 늘어나게되고, 정확한 히스토리 관리가 안된 경우라면(혹은 확인이 어려운 경우라면) 결국 이전에 진행되었던 테스트를 다시 수행해야하는 상황이 발생한다. 경험상 프로젝트의 주된 수정은 중심 컴포넌트들에 집중되고, 해당 컴포넌트들은 테스트 히스토리도 방대해 추가기능에대한 설계/기능에 집중하기 어려울 정도로 기존 기능의 검증에 시간을 할애해야 하는 경우가 있었다.
   2. TDD 활용 시 이점
      1. 불확실성이 높은 상황에서 큰 효과를 볼 수 있다.
      2. 개발 구현 전 설계 과정에서 전체 서비스의 시나리오를 정리해볼 수 있다.
      3. 빠른 피드백을 통해 오류 발생 지점에 대한 명확성을 얻을 수 있고, 오류를 빠르게 고칠 수 있음.
   3. TDD 활용 시 단점
      1. 개발 속도가 약 10 ~ 30% 정도 길어질 수 있음.
      2. 단위 테스트 기반의 테스트만으로는 시스템 테스트를 모두 커버하지 못함.
   4. 결론
      1. 진행하는 프로젝트는 서비스 주제 및 기술 스택 모두 원활히 사용 가능할정도로 완숙하지 않은 상태로, 불확실성이 굉장히 높다.
      2. 구현 과정에서 많은 에러를 마주할 것으로 예상되고, 에러에 집중하는 과정속에서 필수 비즈니스 로직을 놓쳐 전체 개발 시간이 지연될 가능성이 높아 보인다.
      3. 따라서 오류 피드백을 빠르게 받아볼 수 있고, 오류 발생시점에 빠르게 고치고 넘어갈 수 있는 TDD를 활용해 개발하는 것이 사용하지 않는 것보다, 서비스 구현 완성도와 구현 속도(에러 디버깅 속도를 높여 전체 구현 시간을 줄일 수 있을것으로 기대) 측면에서 더 나은 방법으로 생각하여 TDD를 활용하기로 한다.

프로젝트 구조

TBD

Tree > *.txt

기간별 목표

• 1기간(2023.02.15 ~ 2023.02.17) : 프로젝트 설정 및 설계
  • DB 설계
  • Entity 설계
  • API 스펙 설계
  • GitHub Actions 설정 : 코드 컨벤션 검사
  • H2 데이터베이스 설정
• 2기간(2023.02.18 ~ 2023.02.19) : TDD 로 API 구현
  • 회원가입 API 구현
  • 계좌조회 API 구현
  • 친구추가 API 구현
  • 친구목록조회 API 구현
  • 송금하기 API 구현
• 3기간(2023.02.20 ~ 2023.02.22) : 네이버 클라우드 연동
  • MySQL 데이터배이스 설정
  • 네이버 클라우드 DB 설정
  • 네이버 클라우드 Compute server 설정
  • 네이버 클라우드 연동 및 테스트
• 4기간(2023.02.23 ~ 2023.02.26) : 대용량 트래픽 테스트
  • 송금하기 API 대용량 트래픽 테스트
  • API 리팩토링
• 5기간(2023.02.27 ~ 2023.03.01) : 최종 정리
  • API 리팩토링
  • 회고록 작성
  • 문서 정리