몇몇 변경요청사항입니다.

[binam33]

• exception 패키지는 common 밑으로 들어가는 게 좋을 것 같습니다.
• domain밑의 client는 기술이름과 헛갈리니 controller 처럼 customer이면 좋을 것 같습니다.
• domain밑의 common은 패키지를 따로 둬야 할까요?
• domain 및 controller(swagger를 통해 보이는) 부분에 노출된 문서에 대한 설명 작성 필요합니다.
• 어느정도 만들고 나서 sonarqube같은 걸로 정적 점검을 한 번 돌려보면 좋을 것 같습니다.

starter는 모든 API개발시 참조할 수 있도록 구성하는 프로젝트이며 다음과 같은 기능이 있습니다.

• 특정 공통기능 사용에 대한 샘플
• MSA구성요소(api호출,redis,kafka등) 연계기능에 대한 샘플
• 로깅,환경 관리, 라이브러리 관리 등 프레임워크 기능에 대한 샘플

공통기능(common)하위는 샘플로, 각 업무기능 개발시 코드로 가져다 쓰며 따로 통제하지 않습니다.
샘플이 되는 비즈니스는 여러개 있으면 좋긴 한데, 헷갈릴 수도 있어, 하나로 만드는 게 좋을 것 같습니다.

[evelyn0410]

1. exception 패키지는 common 밑으로 들어가는 게 좋을 것 같습니다.

exception 패키지는 common 하위로 수정하겠습니다.

2. domain밑의 client는 기술이름과 헛갈리니 controller 처럼 customer이면 좋을 것 같습니다.

client → customer 로 수정하겠습니다. (table , entity , repository)

3. domain밑의 common은 패키지를 따로 둬야 할까요?

common package 하위에 있는 embedded class 는 domain 하위 위치로 (entity,repository 와 동일한 위치) 수정하겠습니다.
그리고 enum 들은 common 하위에 enums package 생성후 해당 위치로 수정했습니다.

4. domain 및 controller(swagger를 통해 보이는) 부분에 노출된 문서에 대한 설명 작성 필요합니다.

Controller , DTO 에 swagger 어노테이션 으로 설명 작성하겠습니다.

5. 어느정도 만들고 나서 sonarqube같은 걸로 정적 점검을 한 번 돌려보면 좋을 것 같습니다.

넵 사내 서버에 sonarqube 설치후 이번주내로 진행하겠습니다.

---

전에 slack 에서 말씀하신대로 ,

1. openfegin 기능

동일 starter service 를 port 를 다르게 띄운후 테스트 하는 방법으로 구성하겠습니다.

2. redis 기능

user 정보 캐싱으로 구현하겠습니다.

swagger , sonarqube 또한 5월 말 이내로 적용하겠습니다.

kafka 는 설정부분까지 작성후, 어떤 기능을 kafka 를 이용할지 결정후 말씀드리겠습니다.

샘플이 되는 비즈니스는 여러개 있으면 좋긴 한데, 헷갈릴 수도 있어, 하나로 만드는 게 좋을 것 같습니다.

도메인은 member 와 customer 2개로 축소하여 수정하겠습니다.

관련하여 의견이나 수정사항 있으면 말씀부탁드립니다!