선생님, 안녕하세요! 개념도에 ProductFinder를 넣어도 되는지 질문드렸던 학생입니다! 제가 "개념은 클래스도 아니고 엔티티도 아니다"라는 말을 확실하게 이해하지 못해 위 질문을 드렸던 것 같아, 확실하게 이해하고자 이렇게 질문드렸습니다!현재 개념도에 나타난 개념들의 이름이 클래스 이름과 같기 때문에 저는 원래개념이 클래스가 아니다라는 말을개념은 클래스의 부분집합이다. 클래스를 모두 넣으면 개념도가 복잡해지니 중요한 것만 선별해서 넣자.라고 해석했는데, 답변을 주신 내용을 통해 유추해볼 때 다음과 같이 해석하는 게 더 적절할 것 같았습니다.개념도의 Product라는 개념과 코드 상의 Product라는 클래스는 별도의 개념이다. 개념도의 Product라는 개념을 코드로 구현한 것이 Product라는 클래스다.제가 이해한 것이 맞는지요? 그렇다면 예를 들어 "ProductCategory"라는 이름의 개념 대신 "Product의 Category"라는 이름의 개념으로 개념도를 작성하고 그것을 ProductCategory 라는 클래스로 구현해도 괜찮지만 편의상의 이유로 같은 이름을 쓰는 건지도 궁금합니다.

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

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

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

안녕하세요. 섹션 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를 사용할 시 테스트 코드는 어떻게 작성하나요?)

강사님이 추구하시는 생각하는 공부에 대해서 많이 고민해보게 되었습니다.그렇다면 강사님이 생각하셨을 때, 이 강의를 보고 공부하는 이상적인 방법은 어떤게 있다고 생각하시나요?예를 들면, 하나의 섹션을 먼저 다 보고 요구 사항 정리부터 다시 시작해보기 아니면 각 강의마다 끝나고 요구사항을 정리해보고 다음 넘어가기.. 등등 강사님도 커리큘럼을 만드실 때 이런식으로 하면 좋을 것 같다가 있으셨을 것 같은데 궁금합니다.

안녕하세요.결제 부분 강의를 보니 payments API를 보면 컨트롤러에서 주문을 조회하고, 사용 할 쿠폰을 조회하고, 포인트를 조회하고, 조회 된 데이터를 PaymentService로 전달하는 스타일이더라구요. 제가 진행중인 사이드 프로젝트도 커머스가 주제입니다. 제 프로젝트도 처음에는 강의 코드 스타일대로 컨트롤러에서 필요한 데이터를 조합하고, 결제를 처리하는 Service 쪽으로 넘기는 형식이었는데, 이게 점점 결제 기능이 고도화되면서 뭔가 컨트롤러에서 비즈니스 로직의 흐름이 보이는게 맞나? 라는 생각이 들게 되었고 어느 순간부터 웬만한 Controller에서는 1개의 xxxService.method()만 호출하고 이 method가 요청에 대한 비즈니스 로직을 전부 담당하게 되었습니다.@Service class QuestionPaymentService( private val questionOrderGenerator: QuestionOrderGenerator, private val promotionApplier: PromotionApplier, private val orderCouponApplier: OrderCouponApplier, private val paymentCouponApplier: PaymentCouponApplier, private val questionPaymentRecorder: QuestionPaymentRecorder, private val pointCommandAPI: PointCommandAPI, private val eventPublisher: EventPublisher, ) { @Transactional fun payment(command: QuestionPaymentCommand): QuestionPayment { val order = questionOrderGenerator.generateQuestionOrder(command.userId, command.questionIds) val questionPayment = QuestionPayment.create(command.userId, order) promotionApplier.apply(order) orderCouponApplier.apply(questionPayment, command) paymentCouponApplier.apply(questionPayment, command) pointCommandAPI.usePoint(questionPayment.userId, questionPayment.realAmount) questionPaymentRecorder.record(questionPayment) eventPublisher.publish(toEvent(questionPayment)) return questionPayment } }위 코드는 제 프로젝트의 결제 부분인데요. 강의에서 말씀하신 것처럼 Service가 너무 많은 걸 알게되더라구요.(주문도 생성하고, 쿠폰도 적용하고, 프로모션도 적용하고...)지금 이 글을 작성하다보니, 갑자기 제 코드가 못생겨보이네요..강의 코드와 비슷한 방식으로 위 코드를 바꿔본다면, 컨트롤러에서는 orderService를 이용해서 주문을 생성하고, couponService, promotionService 등을 이용해서 전처리를 한 뒤 PaymentService을 이용해 실 결제 금액만큼 금액을 지불하도록 하는 로직과 결제 내역을 저장하는 로직만 있을 것 같아요. 반대로 제 프로젝트 방식대로 강의 코드의 payments API를 만들어본다면, Payment를 만들기 위해서PaymentCreateService와 같은 곳에서, orderReader, ownedCouponReader, pointReader 등을 조합해서 Payment를 생성하는 방식이 될 것 같아요.결국 Service가 적은 책임만 가지게 된다면, Controller 입장에서는 복잡한 요청을 처리하기 위해선 다양한 Service를 조합하게 되고 Controller가 비즈니스 로직의 흐름을 보여주는 형태가 될 수 있다고 생각이 드는데요.(사실 Controller가 비즈니스 로직의 흐름을 보여주면 안된다는 걸 어디서도 듣지 않았지만 뭔가 어색한 것 같아요.)물론 계속 말씀하시는것 처럼 정답은 없다는 것은 알지만, 그냥 단순히 재민님은 주로 많은 책임을 가지는 Service보다는 Controller에서 작은 단위의 Service로 조합해서 처리하는 것을 선호하시는지 궁금합니다.재민님을 지속 성장 가능한 소프트웨어 포스팅으로 알게되었고, 유튜브에서도 많은 도움이 되었어요.그렇게 얻은 다양한 인사이트들을 개인 프로젝트에도 적용해보면서 다양한 시도를 하고 있는데 마침 제 관심사인 커머스 주제로 강의가 나와서 정말 행복합니다.

안녕하세요 토비님 🙃여러 데이터 접근 기술을 병행해야 하는 상황에서, 도메인 모델과 JPA 모델을 분리해서 관리하고 있습니다.이때 한 가지 궁금증이 생겼습니다.RDB 외의 데이터 접근 기술(예: Redis, MongoDB 등)을 고려하면 도메인 모델에서도 식별자(ID) 개념이 필요할 것 같은데, 이런 경우 도메인 객체가 ID를 직접 가지는 것이 괜찮을까요?만약 괜찮다면, 이는 RDB의 책임(시퀀스, AUTO_INCREMENT 등)에 위임하지 않고, 별도의 UUID나 Snowflake ID 등 도메인 차원의 식별자 생성 전략을 두어야 할 것 같은데 이런 방향성에 대해 어떻게 생각하시는지 궁금합니다.

도메인이 뉴닉네임이랑 기존 닉네임이랑 2번을 결제해서 같은 도메인 주소가 2개 떴어요. 그리고 연결을 하나 했는데 인증서 설치 완료가 안떠요.

안녕하세요.버티컬 스크롤 위젯이 웹에서는 잘 작동하는데, 모바일에서는 작동하지 않는 것 같습니다.원래 이런 건가요?

안녕하세요. 지금 22강을 따라서 진행하고 있습니다.본문에 Animated Text를 넣는 부분을 실습하고 있는데, 두 가지 질문이 있습니다.Before / Animated / After Text가 각각 라인이 분리돼서 표시됩니다. 이 부분을 한 줄로 표시하도록 변경하는 옵션이 있나요? 현재 사용중인 플러그인의 버전은 아래와 같습니다.  강좌에서 설명해주신 것처럼 Before/After Text와 Animated Text의 크기를 다르게 설정하는 옵션을 찾을 수가 없는데, 설치된 플러그인의 버전(vs. 강좌) 차이일까요?* 혹시 강좌에서 사용한 버전은 어떤 걸까요?

안녕하세요. 이유는 확실히 모르겠지만 갑자기 엘리멘터 라이센스 키가 일치하지 않는다고 하네요.. 최근에 카페24 호스팅이 만료 되어서 오늘 다시 연장했는데 혹시 이 것 때문인지 모르겠어요. 엘리멘터 다시 설치 하려면 어떻게 해야 할까요?  

 강의에서 컨테이너에서 사진 추가하고 하면 사진이 화면 가득 찬다고했는데 저는 가득 차지않아서요 full 부분도 했습니다. 레이아웃으로 수동으로 키워야하는 수준입니다.

안녕하세요!제가 얼마 전에 맛보기 영상을 통해서 엘리멘트 프로를 제공한다는 걸 보고서 강의를 결제했습니다! 저는 당연히 강의를 결제하면 무료로 제공이 되는 것인 줄로 알고 다운을 받지 않고 있었는데, 오늘 보니 갑자기 이벤트 종료로 다운을 받을 수가 없어서요ㅠㅠ 제가 이것 때문에 타사이트의 강좌가 아닌 인프런을 통해 해당 강좌를 신청해 듣고 있는데, 혹시 엘리멘트 프로를 제공 받을 수 있는 다른 방법은 없을까요?

제가 아직 이강의를 다 들은건아닙니다..이걸듣고나서 크몽에서 홈페이지를 만드는 부업을 하고싶은데요.이것만으로도 충분한지 궁금해요.고가의 홈페이지의뢰를 받을생각도없고 기본적인 크몽에서 15만원정도 단가하는 수준으로요궁금합니다.