아키텍처 레이어

v1 → v2 migration시 유의사항

• Club 도메인의 스켈레톤 코드를 작성하면서, v1의 코드를 v2로 마이그래이션 할때 여러가지 주의 사항을 발견하였습니다! 반드시 아래 주의사항 꼭 고려해서 코드 작성해주세요!
• 테스트코드! 로그!!
  • 로그 단계학습

1. 나중에 주석 삭제

2. Internal API 설명

   • 지금 고민되는 사항이, InternalApi로 인해 service단에서 중복되는 코드가 발생할 수 있을 것 같음 그래서 그냥 다른 모듈의 비즈니스 로직에 접근할 때, 바로 해당 도메인을 가져다 쓰는식으로 하는게 더 좋을 수도 있을 것 같은데 이러면 단점이, 해당 도메인이 변경시에 다른 도메인에 사이드 이펙트가 커짐. 근데 생각해보면 결국 InternalAPI로 접근한다고 하더라도 도메인 변경시에 사이드 이펙트가 커지는 건 마찬가지. 따라서 결국 의존성을 낮추는 방식으로 도메인을 설계하는 것 밖에 방법이 없음
   • club조회
     • 메인화면에서 전체 동아리 조회 → Club조회
     • AdminId → Role → Club 조회

3. Controller의 Url Path

   • 예를 들어, @RequestMapping("api/v1/club") 이라면, v1을 v2로 수정하여, URI가 중복되지 않도록 고려!

4. v2의 클래스, 함수, 레코드, 인터페이스 명이 v1와 일치할 경우, Import시 꼭 v2를 참조하도록 다시 한번 확인!

5. Controller에 작성되는 @Tag명은 Swagger문서에 반영되는 사항임. 따라서 영어로 되어 있다면 한글로 작성하자

6. JAVA 코드 린트 → 코드 작성 후에 코드 린트 적용해야 할 것 같음(이건 나중에 할까..)

7. 테스트 코드 이제 반드시 작성하자! 해당 api에서 발생할 수 있는 모든 예외상황 다 테스트 해보기

   • 그리고 실제 더미 클라이언트에서 요청 보내는 것(웹통신)처럼 테스트 할 수 잇는지도 찾아보자

8. PR 작업단위 좀 작게 쪼개자, 지금 v1옮기면서 아마 결합도 때매 충돌나거나, 앞서 구현이 되어야 작업가능한 도메인도 있을 것이다. 그리고 작업하면서 컨벤션 맞춰야 하는것도 언제든지 나올수 잇으니

9. V1 코드는 절대 지우거나 수정하지 말자(복사만 할것!). 만약을 위해

10. 동아리 회장이란 네이밍을 없애고, manager가 어떤지(회장이 중복 가능하니까, 그리고 운영진과 동아리원의 차이는 해당 전형을 조정할 수 있냐 없냐와 권한 부여의 차이)

    

11. 개발할 때 좀 디테일하게 판단 햇으면 좋겠음. 그냥 아는대로만 하지 말고 이거 말고 더 괜찮은건 없는지 이 타입이 적절한지 꼼꼼하게 살펴보기

    1. 예를 들어 지금 동아리 소개글이 말도 안되는 introduction으로 네이밍 한거라든지 DB의 introduction에 단순 문자열만 저장하는 필드인데 왜 json타입으로 한건지 그냥 문장 길게 들어갈 거 같으니까 이걸로 한거 같은데 TEXT나 VARCHAR길이 조정도 있고 LOB이라는것도 있는데 이런 고민이 아에 없는거 같음

12. @Lob쓸건지, 아니면 @Column(columnDefinition = "TEXT") 쓸건지

13. @AllArgsConstructor 지양하자!

    • https://www.inflearn.com/community/questions/1179578/혹시-allargsconstructor-를-지양하시는-이유가-빌더-패턴을-사용하기-위함인가요?srsltid=AfmBOoroxhQLBJ-uOfNypSia50WdBrINlU6oB82B9p7xS7z5YoT9Fu0l

    https://junha.tistory.com/25

    https://velog.io/@mooh2jj/올바른-엔티티-Builder-사용법

    https://roopredev.tistory.com/14

    • 맨 밑에보면 정확히 이해가능

    https://mangkyu.tistory.com/163