[2기 - 아만드] 6주차 RBF

한 주간 배우면서 새로 알게된 개념이나 잘 못 알았던 개념을 서로 나누어 보아요.

• DTO ↔ Entity 변환은 Service Layer에서 해야하는지? Controller(Presentation Layer)에서 해야하는지?

• Service Layer 메소드에서 DTO를 파라미터로 받아도 괜찮을지?

• DTO를 inner class로 묶는 방법은 좋은 방법일까?

DTO를 inner class로 관리하기

DTO를 도메인의 이너 클래스로 관리해, DTO 관리 편의성을 높여봅니다. DTO를 이너클래스로 관리해 개발 편의성을 올려봅니다. 도메인 클래스안에 DTO를 이너클래스로 두는것이 설계상 괜찮은지에 대해서 고민해봅니다. 너무 많은 DTO 클래스가 생겨 관리가 힘들어질 수 있습니다. 만약 Member라는 도메인 클래스가 있다고 해봅시다. 이때 Member를 create하는 기능이 필요할시, MemberCreateRequest, MemberCreateResponse 벌써 두개의 DTO 클래스가 필요해집니다.

https://unluckyjung.github.io/dev/2022/02/20/Dto-InnerClass/

• @ControllerAdvice, @ExceptionHandler

예외처리를 위한 어노테이션 - @ControllerAdvice, @ExceptionHandler

@ControllerAdvice 모든 컨트롤러 전반에 걸쳐 부가적인 동작(예외 처리, 바인딩 설정, 모델 객체 적용)을 해주고 싶은 경우에 사용할 수 있는 어노테이션이다. @ExceptionHandler와 함께 사용해 예외 처리에 주로 사용되긴 하지만, @InitBinder와 함께 사용하여 바인딩/검증 설정 추가(ex. 특정 필드를 사용하지 않도록 설정하거나, 특정 데이터가 들어오면 에러 처리 해주기), @ModelAttribute와 함께 사용하여 전반에 걸친 모델 정보 설정을 해주는 등의 목적으로 사용할 수 있다.

https://velog.io/@joomal/Exception-Handler-ControllerAdvice-ExceptionHandler

• Bean의 접근제어자는 무엇으로 해야하나요?
• private는 빨간줄이 그어지고 public으로 하자니 protected가 가능해서 protected로 해야할까요? 아무것도 작성하지 않으면 default로 private 이외에 가장 접근 범위가 좁아서 작성하지 않는것을 고민하였습니다.
• 필요 x : 차피 스프링 빈에서 꺼내올 수 있음
• 필요 o : 스프링에서 싱글톤으로 관리안되고 Config클래스를 유저가 new 해서 악의적으로 이용할 수 있음

• Mock/ Stub

Mockito @Mock @MockBean @Spy @SpyBean 차이점

https://github.com/cobiyu/MockitoSample Test Double이 왜 필요한 지부터 시작하는 기본적인 테스트 코드부터 한 단계씩 발전시켜나가며 Mockito의 어노테이션들의 정확한 쓰임새에 대해 살펴보겠습니다. github에 케이스별로 파일별로 구분 지어 놨으니 참고 부탁드립니다. 스프링과 Junit을 이용해서 테스트 코드를 작성하다 보면 테스트 환경(database, api)을 구현하는 코드까지 작성해야 하고 실제 테스트할 코드보다 환경을 구현하는 코드가 훨씬 더 복잡해지게 됩니다.

https://cobbybb.tistory.com/16

• Controller 테스트 코드 작성 시 Service쪽 예외 터지는거도 포함해야할까요? 아니면 DTO에 대한 validation만 하면 될까요?
• 테스트에 대한 범위 설정 기준
• DTO에 대한 Validation 테스트를 따로 작성해도 되나요?

• Validation 레이어마다 어느정도까지 해줘야 하는가?

팀 미팅

• Bean
• Controller, Service, Repository를 config로 빈 등록을 해주면 생성자가 수정될때 config쪽도 중복으로 작업해줘야 한다.
• 만약 서비스쪽 생성자가 수정되면 config 서비스 빈 생성자도 수정해야하므로!
• config를 통해 빈 등록을 하는 방식을 사용할 경우 서비스가 커지면 따로 관리 해줘야한다는 점이 있지만, 이런 방법이 나중에 유행 할 수도..?

• DTO
• DTO는 실무에서 인터페이스보다는 클래스로 많이 쓴다.
• 각 요청에 대한 모델을 만들어서 사용한다

ex) SaveUserRequest.class, UpdateUserRequest.class

• DTO가 Repository 계층까지 들어와도 괜찮다!
• Controller는 요청에 대한 값만 전달하는 느낌?이 좋다. DTO <-> Entity 변환은 서비스에서 해주는걸 선호한다.
• 오히려 서비스 메소드에서 DTO를 받아서 로직을 구현하는게 더 좋다. 반환할때도 마찬가지.
• 서비스 메소드에서 여러 파라미터를 막 받는거보다는 DTO로 관리하면 DTO 필드가 수정될때 더 관리하고 쉽다.

• REST API
• rest api에서 리소스는 복수형으로 가져가자. ex) /vouchers , /users
• 검색 기능의 경우 검색에 대한 분기는 서비스에서 가져가자
• 컨트롤러에서 분기를 갖는거보다 서비스쪽 메소드에서 분기를 가져가서 처리하는 형식이 더 나음 (쿼리 파라미터에서의 null값에 대한 처리)
• Querydsl을 사용하면 where절에서 이러한 분기 처리를 해줄 수 있다. (Repository에서 처리해줄 수 있다)
• API에 버전을 표시하면서 얻는 이점은 레거시 API들을 남겨놓으면서 새로운 API로 리팩토링 하는 방식으로 활용할 수 있기 때문이다.
• API 마다 불러오는 서비스가 다를수 있다.
• 한 api에서 여러개의 api가 호출될 수 있다.
• 비동기 식으로 필요한 API를 모두 호출해놓고 묶어서 처리한다.

• DB
• 데이터 조회 시 UUID는 정렬이 제대로 안되지만, autoincrement를 사용하면 id를 통해 자동 정렬이 되서 데이터가 조회된다.

• TEST
• 컨트롤러 테스트는 우선 순위가 낮다. 차라리 통합테스트나 서비스쪽을 더 세세히 짜주는게 좋다
• 컨트롤러 테스트는 실제 api를 호출하면서 검증하는 WebTestClient 를 사용하기도 한다. 통합 테스트는 시나리오를 생각하면서 어떤 부분에 오류가 날 것이라고 예상하면서 짜기도 한다.
• 통합테스트는 보통 API 호출을 기반으로 테스트 한다.
• 이외 복잡한 여러가지 행동들은 QA들이 테스트한다.

• CQRS 패턴
• 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하자
• 메소드를 호출했을때 내부에서 변경(사이드 이펙트)이 일어나는 메서드인지, 아니면 내부에서 변경이 전혀 일어나지 않는 메서드인지 명확히 분리하자
• 그렇게 되면 데이터 변경 관련 이슈가 발생했을 때, 변경이 일어나는 메서드만 찾아보면 된다.

• 아키텍쳐
• 주로 서비스에서 Exception을 던지고 컨트롤러에서 Error코드를 준다(ControllerAdvice)
• 서비스가 두꺼운게 컨트롤러가 두꺼운것보다 낫다