목적

기존 모놀리식 프로젝트 (https://github.com/dasd412/RemakeDiabetesDiaryAPI)를 MSA로 전환한다. 그리고 도커, 쿠버네티스를 적용한다.

---

적용할 기술

1. 도커

2. 쿠버네티스

3. 스프링 클라우드

4. 인덱스 튜닝 및 성능 측정 (더미 데이터 넣고 해볼 예정)

5. git branch 전략 적용

   등등...

   ---

기존 프로젝트 다이어그램

---

영역 구분

---

상호작용 분석

회원 가입과 로그인

아이디 찾기와 비밀번호 찾기

분석해보니, FindInfoService와 WriterService는 통합하는 게 나아보인다. 리팩토링으로 WriterService로 합칠 예정.

일지 CRUD

클래스 다이어그램

시퀀스 다이어그램

DiaryService와 WriterRepository 간의 상호 작용을 확인할 수 있었다. 두 개의 마이크로 서비스로 분해할 수 있는 것처럼 보인다.
그리고 기간 내 일지 조회의 경우는 오로지 DiaryService 영역에서 일어나므로 생략한다.

음식 차트

프로필

1. 프로필 업데이트에서 UpdateDeleteDiaryService가 책임을 갖는 것은 적절치 못하다. WriterService 영역으로 옮겨야 한다.
2. BulkDeleteHelper는 다이어리와 사용자 두 영역을 모두 건드린다. 어떻게 다뤄야 할까.

---

브랜치 전략

소규모 개인 프로젝트이기 때문에 가장 단순한 github branch 전략을 사용한다.

참고 링크

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

---

떠오르는 의문점

1. 기존 테스트 코드는 어떻게 이식해야 할까? 특히, 스프링부트 통합 테스트로 이루어진 코드들은 어떻게 분리해야 하는가?
2. 메이븐 내 메이븐으로 이루어진 프로젝트는 어떻게 구성할까?✅
3. 기존 스프링 시큐리티와 관련 어노테이션은 어떻게 구성해야 할까?
4. 마이크로서비스마다 발생하는 로그들은 어떻게 수집하고 저장해야 할까?
5. 마이크로서비스를 나누는 기준을 어떻게 잡아야 할까?