API 명세서 툴 ( Swagger vs Spring Rest Docs)

안녕하세요, bamho 님!같은 프로젝트에서 문서 도구를 2개 이상 쓸 이유는 없어보이고요 ㅎㅎ팀별로 다르게 Swagger를 쓰는 팀도 있고, REST Docs를 사용하는 팀도 있습니다.무엇을 선택하느냐는 각 도구의 장단점에 맞게 선택하면 될 것 같아요.제가 속한 현재 팀에서는 개발 속도를 고려하여 Swagger를 사용하고 있지만, 개인적으로는 테스트 코드 기반의 REST Docs를 사용하는 것을 선호합니다.감사합니다. 🙂

재고 엔티티 설계

안녕하세요, springYam 님!이전에 재고 관련해서 비슷한 질문을 하신 분이 계셔서, 해당 답변 참고하시면 좋을 것 같아요.감사합니다. 🙂

@Builder 관련 문의

안녕하세요, bamho 님!맞습니다. 생성자 대신 Builder를 쓰는 이유는, 빌더 패턴을 통해 각 필드를 명시적으로 표기함으로써 코드의 가독성을 가져가고가 하는 취지에요.보통 실무에서 사용하는 객체는 필드가 수십 개가 넘어가는 경우도 꽤 흔한데요, 생성자로 그 많은 값들을 주입하려면 타입이나 순서를 고려하여 값을 넣어야 하기 때문에 많은 위험을 감수해야 합니다.빌더 패턴을 사용하면 필드명을 보면서 데이터를 명시적으로 주입하기 때문에, 여러 면에서 이점이 있습니다.빌더를 내부에서만 사용하도록 private으로 설정하고, 외부에서는 정적 팩토리 메서드 등으로만 인스턴스를 생성할 수 있도록 하는 방법도 있으니 참고해 주세요.감사합니다. 🙂

@Value 관련 환경변수 주입 테스트코드 질문..

안녕하세요, bamho 님!전체 프로젝트를 확인한 것은 아니지만, 보통 test yml 프로파일에 테스트용 값을 직접 명시하면 Value로 잘 주입될 거예요.차선책으로 해당 객체의 사용처를 고려하여 MockBean 처리를 하는 방법도 있으니 참고해 주세요.감사합니다. 🙂

다른 섹션ppt도 받을 수 있을까요?

안녕하세요, 성관 님!macOS 에서 압축하면서 파일이 깨져서 올라갔나 보네요 ㅠㅠ현상 확인 후 다시 재업로드 하였습니다. 감사합니다 🙂

ResponseDto 위치 질문

안녕하세요, bamho 님!이전 강의 중에 request DTO에 대해, Controller Request에서 Service Request로 변환해준 내용 기억나시나요?Service 레이어가 Controller 레이어에 의존하지 않도록 DTO 간 변환 처리를 해준 것이었는데요.마찬가지 이유로 현재 강의 예제의 Response 객체는 Service에서 만들어지기 때문에, Service 레이어 쪽 패키지에 두고 Controller가 이를 자연스럽게 의존하도록 둔 것이라 이해해주시면 됩니다.레이어 간 의존성의 방향이 한 곳으로만 흐르도록 설계해 준 것이죠.도움이 되셨기를 바랍니다.감사합니다. 🙂

@RestControllerAdvice 와 @Validation

안녕하세요, 조희제 님! 컨트롤러 테스트 할 때 빈 validation이 적용 된 모든 필드를 하나씩 모두 검증 하나요?테스트는 항상 자신이 필요하다고 생각하는 범위에 적용하시면 됩니다.모든 필드를 검증하는 것이 물론 좋으나, 주어진 시간과 필드 중요도에 따라 선택할 수도 있는 것이죠.상황에 맞게 결정하시면 됩니다.저도 시간이 충분하다면 최대한 많이 검증하는 방향으로 테스트를 작성합니다. 공통 예외 처리는 어떻게 하는게 좋을까요?특수한 경우가 아니면 도메인 Controller 별로 Advice를 두기 보다는, 공통 Advice 하나에서 우리 시스템의 에러 응답 포맷과 정책을 관리하는 편입니다.보여주신 예시에서는 GeneralAdvice 하나만 관리하는 형태인 것이죠. 도움이 되셨기를 바랍니다.감사합니다. 🙂

when then이 깔끔하게 나눠지지 않으면 주석을 어떻게 다는 편인가요?

안녕하세요, changi1122 님!저는 전자처럼 작성하는데요, 후자는 주석을 위한 코드 스타일이 되는 것 같아 어색해 보이네요. 읽는 사람에게 의도를 전달할 수만 있다면 충분하니, 주석에 너무 얽매이지 않으셔도 괜찮습니다. 감사합니다. 🙂

JPA 를 사용하면 원래 객체지지향적인 설계를 가져가기 어렵나요?

안녕하세요, PrivilegeEscalate 님!주신 코드만 봐서는, 비교하는 필드가 변하지 않았는데, getter 비교 방식에서 메서드 방식으로 변경되었다고 추가적인 쿼리가 나가는 상황이 잘 이해가 가지는 않는데요.예시로 들어주신 코드를 보면, 식별자인 id 필드만 비교하기에 방식이 변경되었다고 추가적인 쿼리가 나갈 것 같지는 않아요.만약 Crew 내에 즉시로딩 하는 객체가 있었다면 그럴 수도 있겠지만, 그런 상황이 생길 것을 고려한다면 애초에 지연 로딩이나 fetch join을 사용하는 것이 자연스러워 보입니다.JPA를 사용해서 객체 지향적인 설계를 가져가기 어려운 것이 아니라, JPA를 사용하기 때문에 fetch join 처럼 고려해야 할 지점이 생기는 것이라 이해하는 것이 좋겠습니다.감사합니다. 🙂

spring security @AuthenticationPrincipal rest docs 질문

안녕하세요, leeseongju 님!구현하신 내용에 따라 방법은 여러가지가 될 수 있겠는데요. SecurityMockMvcRequestPostProcessors 나 @WithMockUser 등에 대해 학습해보고 적용해보시면 좋을 것 같아요.참고 : 블로그감사합니다 🙂