구름 핀테크 개발자과정 1회차
[ 김재근 , 윤효정 ]
주제 선정 이유(펀딩 왜?) -> 실제적인 금융경제 모델을 구현함으로써 금융플랫폼 구조를 이해하는데 도움이 되고, 다양한 기술적 요구사항을 구현해볼 수 있음( 인증, 결제시스템, 동시성제어 등)
기술 선택 이유
-> 안정적인 자바와 스프링부트. 펀딩은 금융관련 높은 트래픽이 발생하지 않을것으로 판단해 ORM으로 구현. (재근)
-> 각종 조회요청이 주가 될 것으로 판단, 조회용 테이블을 추가해서 조회성능 개선
REST api -> (효정) -> 엔드포인트 설계, 컨트롤러 작성
프론트 페이지 구현 -> (효정)
클린아키텍처 기반 설계 -> (재근)
-> 장기적인 확장, 유지보수성 향상을 위해
-> 초반 개발속도를 위해 클린아키텍처의 원칙을 일부 손상키시더라도 도메인 계층에 JPA와 스프링부트 어노테이션을 사용
레이어드 아키텍처로 변경 -> (재근)
-> 개발인력과 기간에 맞추기 힘들것으로 판단해 익숙한 레이어드아키텍처로 변경.
-> 클린아키텍처로 마이그레이션 예정
동시성제어 -> (재근) -> 상품 입/출고, 펀딩금액이 변경되는경우 베타락을걸어 조회/쓰기 막음.
캐싱 -> (재근) -> Redis사용해서 멤버정보 캐싱. 만료시 DB에서 조회 후 캐싱
테스트코드, 테스트명세서 작성 -> 예정
예외처리 -> (재근, 효정) -> 시큐리티 설정에서 403, 401 필터링. 404는 403으로 통합.
자동배포관리(Slack 등에 결과전송) -> (재근) -> 무중단배포 고려(blue/green 전략)
토큰기반 인증필터구현(access, refresh) -> (효정, 재근) -> refresh토큰은 redis에 저장 후 관리. 로그아웃시 토큰파괴 -> 기존 구현해둔 인증서버 활용 고려
중복로그인 방지전략 -> (재근, 효정) -> csrf토큰에 임의 문자열을 발행과 동시에 캐싱. -> 로그인시 csrf토큰이 재발행되며 기존 토큰에 저장된 문자열이 캐싱된 문자열과 다르므로 인증거부.
정보 암호화 -> (효정) -> 추후 리액트로 fe 구현시 추가예정
Api 문서화(Swagger) -> 예정
협업도구 활용 -> Monday.com 으로 프로젝트 일정 관리. 스프린트 진행, 작업별 중요도와 상태 설정 -> Github 활용 -> slack에 github repository와 monday.com 연동하여 프로젝트관련 알림 수신 -> draw.io -> erd cloud
형상 관리 -> Github Flow방식 적용 -> feature/AuthController-implement 형식의 브랜치 생성 후 수정 적용 -> 작은 단위로 자주 커밋하여 추적이 용이하게 함 ( 소규모 팀과 프로젝트에 적합, 프로젝트가 커지고 복잡해지면 Git flow, Gitlab flow로 변경 하는게 좋음)
관리자 페이지 -> (효정)
트래픽 테스트(Jmeter)@ -> (미정) 다중언어설정 -> (미정)