Controller / Service 분리

안녕하세요, 조희제 님! 1. Controller를 행위에 따라 부분적으로 분리 하여도 괜찮나요? UserController / EventController / VerificationController이렇게 분리하는 것보다는, 도메인이 우선되도록 나누는 것이 좋을 것 같아요.UserController 내에서 유저 관련 검증 API가 너무 많아지면 UserVerificationController 로 나누는 것을 고민해 보는 것이죠.말씀주신대로 나누면, 반대로 다루는 서브도메인의 종류가 많아질수록 각 Controller는 비대해질 수밖에 없습니다. 2. Controller / Service 책임을 어떻게 설정 하시나요?이것도 마찬가지입니다. 가장 먼저 도메인을 중심으로 나누고, 그 안에서 책임이 많아졌다고 느낄 때 세부 클래스로 나눠보세요. ex. UserCreateService즉, 핵심은 항상 도메인입니다.도움이 되셨기를 바랍니다.감사합니다 🙂

CQRS에 대한 jpa interface에 대한 궁금증..

안녕하세요, 쌤수 님!좋은 고민이네요. 간단한 수준이라면 편의를 위해 Command 쪽에 Query성 쿼리 메서드를 두는 방법도 선택할 수 있긴 합니다. (어느정도 감안을 하는거죠.)만약 복잡한 프로젝트이거나, 철저하게 분리를 하려면 말씀하신대로 QueryDSL로 분리하는 방법을 사용하면 될 것 같네요.감사합니다 🙂

stubbing을 해줘야 하는 이유

안녕하세요, 김상형 님!너무 잘 정리해 주신 것 같아요. 핵심은 말씀해주신 것처럼 테스트하려는 대상에만 집중하고, 내가 제어할 수 없는 외부 세계의 영역을 stubbing(mocking) 한다, 라고 이해해주시면 됩니다.감사합니다. 🙂

테스트코드 범위

안녕하세요, wnsqud70 님!음, 아닙니다. 강의에서 보여드린 형태로 Controller에 대한 단위 테스트와 Service 통합 테스트, Repository 레이어의 단위 테스트 정도가 가장 좋다고 생각합니다. (물론 여기서 더 나아간다면 전체 범위를 대상으로 사용자 행동 시나리오에 기반한 인수 테스트까지 작성해볼 수도 있습니다.)그 이상으로 더 촘촘하게 테스트하는 것은 투자 비용 대비 효율이 적을 것 같아요.도움이 되셨기를 바랍니다.감사합니다. 🙂

findProductsBy 메소드에서 왜 Map 을 만들어 찾는지 잘 이해가 안됩니다

안녕하세요, ewgregerg c 님!강의 중에도 이야기하지만, 동일한 상품을 여러 개 주문한 경우를 대응하기 위함입니다.productRepository에서 바로 return하면, 같은 상품 여러 개에 대해서는 하나의 Product만 반환되기 때문에, 이후 과정에서 의도한대로 상품 1개 당 Product를 사용할 수가 없게 됩니다.해당 상황을 재현하면서 다시 고민해 보시길 바라요.감사합니다. 🙂

MockBean Deprecated

안녕하세요, 박소연 님!네, MockitoBean으로 대체해서 사용하시면 될 것 같아요. 아래 김상형 님께서 아주 상세하게 잘 안내해 주셨네요.감사합니다 🙂

저는 왜 OrderCreateRequest 에 기본 생성자가 없는데도 주문 신규 생성 호출이 되는건가요??

안녕하세요, ewgregerg c 님!음, 글쎄요. 강의 내용을 모두 동일하게 따라하셨다면, POST 요청 시 기본생성자가 없는 경우 InvalidDefinitionException 예외가 발생할텐데요. 올려주신 내용만 가지고는 제가 파악하기가 어렵습니다. 버전이나 설정 등의 차이가 있는지 확인해보셔야 할 것 같아요.감사합니다 🙂

Mock & Stub 에 대한 이해

안녕하세요, 홀리몰리 님!충분히 가질 수 있는 고민이라는 생각이 드네요.Mockito의 mock 객체를 사용해서, 상태 검증만 한다면 stub 테스트, 행위 검증까지 한다면 mock 테스트라고 볼 수 있겠지만, mock 객체를 사용해서 stub 테스트를 했다고 잘못 되었다고 보지는 않습니다. 이미 인지하고 계시듯이 보통 개발자들끼리 소통할 때도 mock과 stub을 엄밀하게 구분하면서 이야기하지는 않고, mock이라는 용어로 포괄적으로 사용하는 것을 볼 수 있는데요.(stubbing이라는 용어보다는 mocking이라는 용어가 더 친숙한 것처럼요.)개념적으로만 이해하시면 되고, stub이든 mock이든 검증하고자 하는 방향성에 맞게 사용하시면 될 것 같아요.도움이 되셨기를 바랍니다.감사합니다 🙂

Stub vs Mock을 설명하면서 예시가 이해가 안돼요.

안녕하세요, lch9502 님!네, 맞습니다. mock으로 사용되었는지 stub으로 사용되었는지를 보려면 검증부까지 확인해야 하는데요. stub으로 만들어진 객체를 검증부에서 호출 여부, 횟수 등의 행위 검증을 하게 되면 mock이라고 볼 수 있겠습니다.설명을 하다 예시를 간단하게 이야기 하다보니 설명이 충분하지 못했네요. 이 부분은 강의 설명란에 추가 기재하도록 하겠습니다.감사합니다. 🙂

중복된 메서드 줄이는 방법

안녕하세요, 조희제 님! Dto에 인터페이스를 적용 하자니 Dto에 역할을 부여 하는 것이 맞나? 라는 생각이 듭니다.DTO도 Object, 즉 객체인데요. 인터페이스를 적용하는 것이 크게 어색하지는 않다고 생각합니다.역할을 부여한다기 보다는 객체의 공통적인 특성을 명시하는 것이니까요.두 DTO의 이름을 보아하니 비슷한 역할을 하는 DTO 같고, 상황에 따라 ID를 추출하는 부분을 인터페이스로 뽑을 수 있을 것 같아요.추가적으로, 비슷한 DTO가 매우 많다면 이런 고민을 할 수 있겠지만, 2개 정도면 저렇게 private method 추출로도 충분히 핸들링할 수 있다고도 생각합니다. 항상 중복 제거만이 능사는 아니니까요 ㅎㅎ도움이 되셨기를 바랍니다.감사합니다 🙂