안녕하세요! 너무 구현적인 질문을 드리는 걸 수도 있지만, 개념을 나누고 이를 결과적으로 코드로 구현해보려는 입장에서 어느정도 규칙이나 일관성을 두고 구현하면 더 좋겠다는 생각에 질문드립니다! 현재 구현상으로 1. 하나의 개념을 한 서비스로 만들고, 서비스간의 의존은 피하는 형태로 구현하신 게 맞을까요? 2. 만약 그렇다면, 예를 들어 ReviewService에서 현재는 pointHandler를 호출하고 있는데, 이 핸들러의 로직이 더욱 응집되어 PointService의 메서드 자체를 호출하는 것이 하나의 동작으로써 자연스럽다면, 이런 경우는 PointService를 ReivewService에서 의존해서 메서드를 호출하기보단, ReviewHandler 및 추가로직이 응집된 PointService 서비스 하위레이어(?)를 두어서 이를 의존하게 하는 형태로 구현하시는 건지 알고 싶습니다..!

ReviewService에서 addReview를 할 때, ReviewTarget 객체와 ReviewContent 객체를 넘겨주어서 Validator에서 이를 검증하는 코드를 봤습니다. 이와 같이 개념을 표현하기 위한 객체 내부에 검증 메서드(비즈니스 적인 요소 or 값 누락 등)를 두는 건 좋은 방법이 아닐까요? 예를 들어 validator에서는이러한 개념을 구성하는 요소간 복합 검증이 필요한 경우 이러한 내용을 구현하고, 각 요소 자체에서 할 수 있는 검증은 ReviewTarget같은 객체에서 validate()메서드를 두어, 해당 객체가 갖고있는 데이터에 대한 검증을 하게 한다면 어떨까 생각이 들었습니다.아직 강의를 끝까지 보지 못했지만, 개념 객체 역할을 하는 class가 단순 dto 처럼 값만을 들고 있는 역할을 하는 것 같아 질문드립니다..!

안녕하세요! 격벽은 주요 개념을 나누고 가능한 직접 의존하지 않게 하는 판단 기준이라고 생각이 들었습니다! 그런데 예를 들어 복잡한 조회 쿼리의 경우에는 컨트롤러단에서 각 개념 간 조회를 하고 이를 어플리케이션 단에서 데이터를 필터링하는 것보다 join을 하는 경우가 성능적으로나 구현적으로 나은 방식이 될 수 있을 거 같습니다! 이런 경우 서로 다른 두 개념이 있을 때 한 개념 내 테이블과 다른 개념 내 테이블을 직접 join하는 경우가 있을 거 같은데요, 혹시 이런 경우도 가능한 지양하시는 편이실까요?? 벽을 침범하지 않는다는 것이 이런 경우에도 적용되어야 하는 것인지 궁금합니다!

안녕하세요! 보통 실무를 하다보면 여러 개념이 명확히 떨어지지 않는 경우도 있을 거 같습니다. 예를 들어 예약의 경우는 상품을 고르고, 여러 할인정책이 있고, 쿠폰, 포인트 등 여러 개념이 혼합되어 생기는 개념이라고 생각합니다! 혹시 이런 경우에는 예약도 한 개념이라고 볼 수 있을까요? 그리고 예약이 한 개념이라면 ReservationService를 만들었을 때 ReservationService는 godObject같은 형태가 만들어지기 쉬울 거 같은데, 이런 경우 재민님이라면 어떻게 예약과 다른 개념 간 격벽을 치고, 구현적으로는 어떻게 풀어나갈 것인지 알고 싶습니다!

안녕하세요, 강의 보기 전 소스코드부터 보고 있는데 패키지 구조에 궁금증이 생겨 질문드립니다. 현재 domain 및 db core 패키지 하위에 도메인별 세부 패키지 분리 없이 모든 파일이 배치되어 있는데요, 추후 프로젝트 규모가 커져 파일 개수가 수백, 수천 개에 달하게 될 경우에도 이러한 구조(패키지 미분리)를 유지하시는 것을 선호하시는지 궁금합니다. 감사합니다.

안녕하세요. 오늘도 재미있게 잘봤습니다. 감사합니다.// ReviewManager.kt @Transactional fun delete(user: User, reviewId: Long): Long { val found = reviewRepository.findByIdAndUserId(reviewId, user.id) ?: throw CoreException(ErrorType.NOT_FOUND_DATA) found.delete() return found.id }이 코드를 보면서 삭제를 구현할 때 두 가지 방식이 있겠다는 생각이 들었습니다. 첫번째는 조회 + 삭제, 두번째는 정확한 key를 넘겨주어서 한번에 삭제. 둘 가운데 어떤 방식을 선호하시는지 궁금합니다.처음에는 두 번째 방식으로 구현을 한다면 메서드 이름과 동작이 더 일치해서 좋고 코드도 한 줄에 끝나서 더 좋은게 아닌가? 라고 생각을 했었는데 그렇다면 첫번째 방식을 하면 좋은점이 무엇일까 다시 생각을 해보니 만약 삭제할 때 ORM 예외가 발생한다면 ReviewManager가 몰라도 된다는게 장점일 수 있겠다는 생각이 들었습니다.  

현재는 클라이언트에서 넘어온 amount를 검증하고 있는데 이는 조작 위험이 있지 않은지 궁금합니다.예를 들어 1원만 결제하고 서버에는 10000원을 결제했다고 보내면 서버에서는 결제 승인 API를 호출하여 totalAmount를 확인하기 전까지는 알 수 없는걸까요?결제 승인 API에서 반환되는 Paymet 객체에 totalAmount 필드가 있기는 하지만 결제를 승인하기 전에 toss 서버에서 실제 결제된 금액을 조회하는 방법이 따로 없는건지 궁금합니다

강의를 듣고 재민 님이 말씀해주신대로 코드를 옮겨 봤는데요.ProductFinder에 findSections 메서드가 있지 않고 ProductSectionService에서 ProductSectionRepository를 통해 바로 조회하는 것도 꽤 자연스럽고 괜찮다고 느껴졌습니다.그런데 여기서 궁금한게 있습니다. Product 관련한 건 ProductFinder 라는 별도의 객체가 책임을 갖게 해서 코드를 짜다가, ProductSection에서 갑자기 바로 Repository에 접근해서 조회를 하도록 하면 코드 통일성 측면에서 바람직한가? 하는 의문이 문득 들더라구요.그렇다고 ProductSectionFinder를 또 만들어서 하자니 너무 과한가? 싶은 생각도 들었습니다. 추가로 ProductSection 조회에 다른 요구사항이 생기거나, 복잡한 구현을 해야 된다면 ProductSectionFinder 같은 걸 만들어도 좋을 것 같은데, 현재 시점에서 만드는 것이 좋은 접근인지 확신이 안 생긴달까요 ㅎ만약 이런 고민이 들 때는 어떤 것에 우선순위를 두어서 결정하는 것이 좋을 지 재민 님의 의견이 궁금합니다. 좀 더 자연스러운 흐름대로 짜는 것이 나을지, 혹은 코드 통일성 유지를 위해서 바로 Repository에 접근하는 것은 지양 하면 좋을지 등등 말이죠!이건 회사나 팀마다 정해진 규칙이 있을 가능성이 높지만 공부하는 입장에서 궁금증이 들어 이렇게 질문을 드립니다. 감사합니다😀

쿠폰 챕터 부분에서 "코드 느끼기" 강의의 7~8분대에 CouponController 부분에 getOwnedCoupons 에 대해 강의에서는 "내가 받을 수 있는 쿠폰 목록 전체를 내려준다"고 말씀하셨습니다. 그런데 제가 이해하기로는 "다운로드 받은 쿠폰(들)을 전체 조회한다"로 생각했습니다.그 이유는 download(다운로드)를 해야만 ownedCoupon 엔티티로부터 데이터를 가져오기 때문입니다.혹시 제가 이해한 것처럼 getOwnedCoupons 의 역할이 "내가 받을 수 있는 쿠폰을 조회한다"가 아닌 "다운로드 받고 난 쿠폰을 조회한다"와 같은 API인지, 혹은 그게 아니라면 무슨 의미인지 알려주시면 감사하겠습니다!강의 내용을 듣다보면, "다운로드 받을 수 있는 쿠폰을 조회한다" , "다운로드 받은 쿠폰을 조회한다"와 같이 의미가 비슷하지만 이해하기 헷갈려서 그렇습니다 ㅜㅜ

먼저 재미있게 강의 잘보고 있습니다. 감사합니다.프로젝트에서 storage 모듈을 보다가 모든 entity가 status를 갖는다는 것을 알게되었습니다.class xxEntity():BaseEntity() // base entity가 status를 갖고 있고 // 위의 코드는 상속이라고 알고있습니다(AI로 확인해봤는데 만약 아니라면 민망할것같네요...)모든 entity가 상태가 필요한가? 하는 생각이 들어서요. 아니면 status를 기본으로 설정하면서 어떤 장점을 의도하려고 하신건지 궁금합니다.

안녕하세요 제미니님 강의를 보다 궁금한 점이 생겨 질문드립니다.리뷰 작성 시 주문아이템 건에 대해 한 건의 리뷰만 작성 가능하도록 요구사항을 잡고 작성하셨습니다.따라서 새로운 리뷰를 작성할 때 해당 상품에 대한 주문아이템 리스트를 조회하여 아직 기간 내에 작성하지 않은 주문아이템이 있을 시 작성이 가능하도록 하셨는데요.이런 경우 ReviewKey없이 바로 주문아이템 건에 대한 FK를 잡아도 될거 같은데 FK를 잡지 않고 ReviewKey를 별도로 만드신 이유가 궁금합니다 !

안녕하세요!리뷰 쪽 강의를 듣다가 궁금한 점이 있어 질문드립니다.강의에서는 findReviews를 제외하고 나머지 기능은 Implement Layer를 통해 각각 값을 전달하는 구조로 되어 있는 것 같습니다.저도 코드 응집도를 높이기 위해 비슷한 구조를 사용 할때가 있는데 실제로는 ReviewService가 여러 작은 서비스에 위임하는 퍼사드 역할을 하게 되는 경우가 있습니다.이런 퍼사드 서비스는 테스트를 어떻게 하는 것이 좋을지 고민입니다. 제가 생각하기에는,1. 통합 테스트를 통해 전체 흐름을 검증하거나2. 각 작은 서비스들을 목(Mock) 혹은 페이크로 대체하여 호출만 검증하는 방법이 가능할 것 같은데 어느 방법이 더 적합한지 확신이 없어 질문드립니다.

안녕하세요!강의를 새로 구매했는데, 이전에 구매했던 강의 내용과 겹치는 것 같아수강하기 전에 미리 여쭤봅니다! [이전에 구매했던 강의]면접 전에 알고 가면 좋을 것들 - 신입 Java 백엔드 개발자편 [새롭게 구매한 강의]모든 웹 개발자가 봐야 할 단 한 장의 지도 혹시 새롭게 구매한 강의가 기존에 있던 강의 내용과중첩되는 내용일까요? 감사합니다.  

강의를 보다보니 궁금한 점이 있어 질문 남깁니다. 첫번째로 궁금한 점은 AbstractPagingItemReader의 코드를 doRead 함수 안에서 lock을 잡고 있으며, doReadPage가 끝난 후 lock을 푸는 것을 확인할 수 있었습니다..doReadPage에 실제로 paging 로직이 존재하니 사실상 paging 로직은 직렬로 수행되는 것과 다를 바 없을 것이며, 성능적으로 크게 증가하지 않을 것 같다는 생각이 드는데요.. (거의 직렬 처리와 유사할 것 같다는 생각이 드네요..) 사실상 병렬 처리라해도 Reader쪽에서 성능 향상이 거의 없다고 보면 될까요? 두번째로 궁금한 점은 AbstractPagingItemReader 상위 클래스인 AbstractItemCountingItemStreamItemReader의 read 함수를 보니 멤버 변수인 currentItemCount를 증가시키는 로직이 존재하더라구요..  이 부분도 병렬처리에 문제가 될 것 같다는 생각이 들고 해당 클래스의 주석에도 "Subclasses are inherently <b>not</b> thread-safe." 라고 적혀있는 것으로 봐서는 문제가 존재하는 것 같은데요.. 그럼에도 불구하고 기능상 영향이 없으니 하위 클래스인 AbstractPagingItemReader는 thread-safe하다고 나와있는 것이라고 생각하면될까요??

안녕하세요. 섹션 2까지 수강한 뒤, 몇 가지 궁금한 점이 있어 질문드립니다. 1. 섹션 1 상황 정의 관련섹션 1 상황 정의에서 다음 이미지와 같이 상황을 정의했습니다.   이러한 초기 시스템과 비즈니스 상황을 가정할 때, 다음 두 가지 사항이 궁금합니다.서버 스펙: 현재 두 대의 서비스 서버에 대해 강의에서 가정한 하드웨어 스펙(CPU 코어 수, 메모리 용량 등)은 어느 정도일까요?인프라 예상 투자 비용: 초기 시스템 구성(서버, DB, 로드 밸런서 등)을 위해 현실적으로 투자 가능하다고 설정한 예상 비용 규모는 어느 정도였는지 궁금합니다. 2. 섹션 2 상품과 카테고리 개념도 관련섹션 2에서 다루신 상품과 카테고리 개념도에서 ProductCategory를 Product의 하위 개념으로 이해했습니다. 이 경우, Category와의 의존성만 끊고, 객체를 직접 참조하도록 설계하는 것이 더 직관적일 수도 있을 것 같다는 생각이 들었습니다. 혹시 실제 설계에서는 ProductCategory 엔티티가 Product 엔티티를 직접 참조하는 대신, productId만을 참조하도록 설계하신 이유나 의도가 있을까요?또한, 일반적으로 엔티티 간의 관계를 설계할 때, 객체를 직접 참조할지 아니면 식별자(ID)만을 참조할지를 어떤 기준으로 판단하시는지도 궁금합니다. 좋은 강의 제공해주셔서 감사합니다. 남은 강의도 열심히 수강하겠습니다!

  말씀해주신 부분에서 Product 객체 응집도를 높이기 위해 서로 Review 객체를 모르는 것이 좋다고 말씀 해주셨는데요. 그럼 코드 내용을 보면 Controller 객체에 Product 객체 하고 Review 객체를 알고 있다는 것 인데요.만약 요구 사항이 Product 데이터 하고 Review 데이터를 가공해서 계산된 데이터를 Client 에게 내려줘야 하는 상황이 있다고 가정 하겠습니다. 그럼 Controller 객체에는 Product 데이터 하고 Review 데이터를 가공해서 계산 하는 비지니스 로직이 분명 있을 것 같습니다. 이것을 Controller 객체에 비지니스 로직이 있으면 Controller 에 대한 역할이 더 분담 되는 것 같아서요. 그래서 제가 생각 한 것은 ProductReview 객체를 만들어서 (어떻게 보면 퍼사드 패턴 이겠네요...)ProductReview 객체가 Product 하고 Review 객체를 알고 Product 하고 Review 객체는 서로 모르는 것이 좋지 않을까 생각 됩니다. 이 방법은 어떻게 생각하시는 궁금 합니다. 굳이 Product 하고 Review 로 대표적으로 설명 해주셨는데 보통 실전에서는 이와 같은 비슷한 상황이 많이 발생 될 것 같습니다.    

안녕하세요 제미니님코드를 보다가 core-enum 모듈에 대해 궁금점이 생겨 질문드립니다.core-enum의 경우 core-api와 db-core에서 의존성을 받아 쓰고 있는데요.core-api가 db-core를 의존성 받아 사용하고 있고 core-enum에 있는 값들은 모두 db-core에서 사용하고 있습니다. 이런 경우 그냥 db-core에 enum 값들이 있어도 될거 같은데 굳이 따로 모듈로 빼신 이유가 궁금합니다 !최대한 생각해본 바로는 db-core를 사용하지 않는 또 다른 모듈에서 사용한다는 가정 밖에 떠오르지 않습니다.혹시 다른 이유가 있을까요?

공부한 내용을 블로그에 정리하려 하는데, 혹시 예제 사용해도 괜찮을까요?

제미니님 안녕하세요 !강의 수강 중 Product와 Category간 개념 정리네 대해 질문이 있습니다 ! 강의를 들으면서 Product와 Category에서 Product가 상위의 개념이라고 선택하시고 매핑 테이블을 네이밍을 ProductCategory을 사용하셨다고 이해하고있습니다 !그런데 개념도를 봤을때.. 개념 간 매핑해주는 ProductCategory가 Product 개념 영역에 있는게 맞는지 의문이 들었습니다 ! Category가 Product 하위의 부가적인 정보로서 ProductCategory가 Product 개념 영역에 존재할 수도 있지만.. 강의에서 설계하는데 있어 Product가 상위 개념으로 판단을 했고, ProductCategory는 Category에 대한 부가정보인데 상위 개념이 하위 개념에 대한 것을 모르도록하는게 맞지 않나 라는 생각이 들어서 질문드립니다 !

안녕하세요! 평범한 대학생 백엔드 개발자 입니다!저희 대학생에게 맞는 강의 영상 찍어주셔서 감사합니다 :) 다름이 아니라 도메인 계층에서 Page를 사용해도 되는지 의문이 발생했습니다.제가 인지한바로는 도메인 계층은 순수한 로직이 이루어져야한다고 알고 있습니다.그래서 저는 도메인 계층에서 Page에 관한 DTO를 하나 생성하고 스토리지 모듈에서 해당 DTO로 반환하게 코드를 작성하였습니다.  그런데 강사님의 코드를 보니까 도메인 계층에서 Page를 사용하고 있더라고요... 단순한 트레이드 오프일까요? 클린 아키텍처와 회사 내 규칙을 따를 것이냐 아니면 개발 편의성을 위해 Page만 허락한다는 등... 그런 것들이 존재할까요? 그렇지만 도메인 계층에서 스프링 프레임워크에 대한 의존성을 갖는게 되지 않을까요... 잘 모르겠습니다! 이렇게 생각하는게 좋은 방향일까요? ㅠㅠ(추가로 도메인 계층에서 Page를 사용할 시 테스트 코드는 어떻게 작성하나요?)