안녕하세요, 2회독 하는중입니다. 확실히 강의 활용하면서 진행하니깐 느끼기(?)가 뭔지 알것같고 궁금한점이 생기네요. CouponService 에서 이미 다운받은 쿠폰은 내려주지 않는 로직을 만들면서 궁금한점이 여러개 생겼습니다.작성하면서 정리하니깐 궁금한점이 계속 꼬리물어서 생긴다고 해야하나 그래서 의식의 흐름대로 적는 것 같아서 미리 죄송합니다 🥲/// CouponService public List<Coupon> getCouponsForMenus(Principal principal, Collection<Long> couponIds) { Set<Long> applicableCouponIds = couponFinder.findApplicableCouponIds(couponIds); Set<Long> downloadedCouponIds = issuedCouponFinder.findDownloadedCouponIds(principal.getId()); Set<Long> downloadableCouponIds = applicableCouponIds.stream() .filter(id -> !downloadedCouponIds.contains(id)) .collect(Collectors.toSet()); return couponFinder.findAllById(downloadableCouponIds); } // CouponFinder public Set<Long> findApplicableCouponIds(Collection<Long> menuIds) { List<CouponTargetEntity> menuTargets = couponTargetRepository.findByTargetTypeAndTargetIdIn( CouponTargetType.MENU, menuIds ).stream().filter(CouponTargetEntity::isActive).toList(); List<CouponTargetEntity> categoryTargets = couponTargetRepository.findByTargetTypeAndTargetIdIn( CouponTargetType.MENU_CATEGORY, menuCategoryRepository.findByCategoryIdIn(menuIds).stream() .filter(MenuCategoryEntity::isActive) .map(MenuCategoryEntity::getCategoryId).collect(Collectors.toSet()) ); return Stream.concat(menuTargets.stream(), categoryTargets.stream()) .map(CouponTargetEntity::getCouponId) .collect(Collectors.toSet()); } CouponService 에서 implement 계층 CouponFinder, IssuedCouponFinder 를 의존하고 있는 상황에서 각 계층끼리 소통할 때강사님 Q/A 답변중에서 가능한 db 엔티티 대신에 개념객체를 넘기는 방향으로 설계하는걸 지향하신다고 말씀하신 답변이 기억이 나는데요, 지금 상황에서는 개념객체까지 변환하는것보다는 id 컬렉션만 뽑아내서 넘기는게 더 효율적이고 깔끔한 것 같습니다.이런 패턴(?) 이 자주 나올 것 같아서 괜찮은지 궁금 합니다.꼭 id 컬렉션을 넘기는게 아니더라도 entity를 반환해야만 매핑하기 편한 경우가 많을 것 같더라구요회원/비회원 요구사항https://inf.run/GTxAx해당 Q/A 를 보기도 했고 마침 강의 활용해서 커피 판매 어플리케이션을 만들고 싶어서 비회원처리가 필요했습니다.public class PrincipalArgumentResolver implements HandlerMethodArgumentResolver { private static final String PRINCIPAL_ID_HEADER = "Gu-Coffee-Principal-Id"; private static final String PRINCIPAL_TYPE_HEADER = "Gu-Coffee-Principal-Type"; @Override public boolean supportsParameter(MethodParameter parameter) { return parameter.getParameterType().isAssignableFrom(Principal.class); } @Override public @Nullable Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception { HttpServletRequest request = webRequest.getNativeRequest(HttpServletRequest.class); if (request == null) throw new CoreException(ErrorType.INVALID_REQUEST, null); Authenticated annotation = parameter.getParameterAnnotation(Authenticated.class); String id = request.getHeader(PRINCIPAL_ID_HEADER); String type = request.getHeader(PRINCIPAL_TYPE_HEADER); validatePrincipal(annotation, id, type); return Principal.of(id, type); } private void validatePrincipal(Authenticated annotation, String id, String type) { boolean isRequired = (annotation != null && annotation.required()); if (isRequired) { if (id == null) throw new CoreException(ErrorType.UNAUTHORIZED, null); if (!PrincipalType.USER.name().equals(type)) { throw new CoreException(ErrorType.UNAUTHORIZED, "회원 전용 서비스입니다."); } } if (type == null) { throw new CoreException(ErrorType.INVALID_REQUEST, null); } } } @Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) public @interface Authenticated { boolean required() default true; } 저는 Authenticated 라는 메타 어노테이션을 사용해서@GetMapping("/v1/issued-coupons") private ApiResponse<List<IssuedCouponResponse>> getIssuedCoupons(@Authenticated Principal principal) { List<IssuedCoupon> issuedCoupons = issuedCouponService.getIssuedCoupons(principal); return ApiResponse.success(IssuedCouponResponse.from(issuedCoupons)); } @PostMapping("/v1/coupons/{couponId}/download") private ApiResponse<?> download( Principal principal, @PathVariable Long couponId) { couponService.download(principal, couponId); return ApiResponse.success(); } public void download(Principal principal, Long couponId) { if (principal.getType().equals(PrincipalType.GUEST)) { throw new CoreException(ErrorType.UNAUTHORIZED, "비회원은 쿠폰을 다운로드할 수 없습니다."); } 애초에 회원만 접근 가능한 api 는 어노테이션으로 처리하던가 서비스 단에서 예외를 던지게 할 수도 있을 것 같아서 이렇게 만들어 봤습니다.이런식의 접근이 괜찮은지당장은 인증객체(Principal)? 랑 User 랑은 다른 개념일 것 같아서 강의내 User 대신에 사용했습니다.@Table(name = "cart_item") @Entity public class CartItemEntity extends BaseEntity { private Long userId; private String guestKey; @Enumerated(EnumType.STRING) private PrincipalType principalType; private Long menuId; private Long quantity; } public class Cart { private Principal principal; private List<CartItem> items; } 마지막으로 장바구니에 비회원도 담을 수 있다는 요구사항이 있다고 가정하면 테이블에는 userId 만 둬서 null 로 구분하는 것 보다 key 필드를 추가하고public interface CartItemRepository extends JpaRepository<CartItemEntity, Long> { @Query("SELECT c FROM CartItemEntity c " + "WHERE (:type = 'USER' AND c.userId = :id) " + "OR (:type = 'GUEST' AND c.guestKey = :key)") List<CartItemEntity> findByPrincipal( @Param("type") String type, @Param("id") Long id, @Param("key") String key ); } 이런식으로 쿼리로 분기처리해야지 생각했는데요. 예전 강사님 Q/A 답변 중에서 쿼리중심의 어플리케이션이 되는걸 지양한다는 느낌의 답변을 봤던 것 같습니다.AI 한테 물어봤을때는 해당 로직은 필터링 목적이니 쿼리로 처리하는게 성능상 효과적이라는 답변을 줬는데요.List<IssuedCouponEntity> issuedCoupons = issuedCouponRepository.findByUserId(userId) .stream() .filter(IssuedCouponEntity::isActive) .toList(); isActive 인 데이터를 가져올 때 강사님이 findByXXAndStatus 로 한번에 가져오거나 혹은 위처럼 filter로 처리하는 두가지 패턴을 보여주셨습니다.이걸 처음 봤을 때, 미세한 성능보다는 filter 로 직관적으로 활성상태인 데이터만 가져온다는 목적을 코드로 보여주는게 더 괜찮겠다고 생각했는데요.근데 이것도 결국 필터링 목적이니깐 메서드 네이밍(findByXXAndStatus)으로 처리하는게 일관성 있는게 아닌지 궁금합니다. 

저는 review image reordering을 염두에 두고 sequence를 계속 가져가는 방향으로 결정했습니다.제미니님은 실무에서 이렇게 염두에 두고 구현이 조금 더 복잡해지더라도 이런 특정 필드나 기능을 가져가는것을 오버엔지니어링이라고 생각하여 피하시는 편인가요? 어떤 기준으로 결정하시는지 궁금합니다.

image only query를 설명해주실때 stable pagination 때문에 조인을 사용하신다고 이해했습니다. 저는 다른방식으로 구현해보았는데 제미니님의 의견이 궁금합니다. 코드를 보면 나중에 image를 fetch 또 하게 되는데 이렇게되면 image only query를 ReviewImageEntity에 reviewId, status 인덱스를 걸고SELECT review FROM ReviewEntity review WHERE review.targetType = :targetType AND review.targetId = :targetId AND review.status = :status AND EXISTS ( SELECT image.id FROM ReviewImageEntity image WHERE image.reviewId = review.id AND image.status = :status 이렇게 구현하는 방식이 데이터량이 많아진다면 효율적이지 않을까 싶어서 구현해봤습니다.

안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 "레거시 다루기" 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요?개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!

ProductOption을 fetch해 올때 DB레벨에서 where이랑 orderby를 하지 않고 애플리케이션 레벨에서 코틀린 filter와 sort를 하신 이유가 따로 있을까요? 성능상 DB에서 전체적으로 데이터를 가져오고 인메모리 작업으로 filter와 sort를 하는게 불리하지 않나 싶어서 질문을 남깁니다.

요구 사항이 자주 변경되는 것을 가정하는 프로젝트인 만큼 isUnique에 관련된 상수나 Recent day에 관한 상수를 properties로 빼서 yml에 관리하는 방식으로 구현해보았는데. 실무에서는 어떤 경우에 yml에서 관리하는 방식을 고려하고 어느 상황에 그냥 상수를 코드에 남기는지 궁금합니다.

안녕하세요.histories() 응답에 PointHistory.id가 포함되어 있던데, 이 값을 내려주신 의도가 궁금합니다.FE에서 이 id를 직접 활용해야 하는 지점이 있는지 궁금해서요.예를 들어 포인트 이력 상세 조회나 특정 이력을 식별해야 하는 기능을 염두에 두신 걸까요?현재로서는 다른 필드들만으로도 충분하지 않나 생각되어, id를 포함하신 이유가 궁금합니다!

@Query( """ SELECT new io.dodn.commerce.storage.db.core.SettlementTargetSummary( settlement.merchantId, settlement.settlementDate, SUM(settlement.targetAmount), COUNT(settlement.id), COUNT(DISTINCT settlement.orderId) ) FROM SettlementTargetEntity settlement WHERE settlement.settlementDate = :settlementDate GROUP BY settlement.merchantId, settlement.settlementDate """, ) fun findSummary(settlementDate: LocalDate): List<SettlementTargetSummary>이부분에서 where절에서 이미 settlementDate를 필터링하고 있는데 group by에서 settlementDate가 필요한 이유가 따로 있을까요? 어차피 parameter로 넘어온 settlementDate만 조회가 되는 로직이라 Group By에서는 필요가 없어보여 질문 남깁니다.

addReview()를 보면 리뷰 저장 이후에 포인트를 지급하는 로직이 함께 들어가 있는데, 제 기준에서는 포인트 지급이 리뷰 작성의 핵심 기능이라기보다 부가 기능처럼 느껴졌습니다.그래서 이런 부분은 서비스 내부에서 직접 호출하기보다 이벤트를 발행하고, 별도의 핸들러에서 처리하는 방식으로 분리해도 괜찮지 않을까 궁금했습니다.(다만 제가 이걸 정말 "부가적인 책임"으로 봐도 되는지 조금 헷갈리기도 합니다.)만약 실무에서는 이런 부가적인 로직을 서비스 메서드 안에 함께 둘지, 아니면 이벤트/이벤트 핸들러 형태로 분리할지를 어떤 기준으로 판단하시는지 궁금합니다.또는 이런 경우 이벤트 외에 다른 방식으로 설계하시는 경우도 있는지 궁금합니다.

안녕하세요~ 강의 중 강사님께서 null을 되도록 허용하지 않는 것으로 보였습니다.공감이 되었는데, CancelEntity.orderItemId 와 같은 곳에 -1 을 설정한 다거나 QnA.answer 에 Answer.EMPTY 를 설정하는 것은 어떤 장점이 있을지 궁금합니다.저는 위와 같은 경우는 해당 필드를 nullable 로 하는 것이 이 필드는 없을 수 있다는 것을 더 명확하게 나타낼 수 있다고 생각했습니다. 좋은 강의 감사합니다!

자바에서 클래스 필드 타입을 참조타입과 원시타입의 차이를 공부하던 중에둘의 차이가 null 값이 필요하냐 필요하지 않냐로 배웠습니다..그런데 엔티티 pk의 경우에는jpa에서 새 객체와 저장된객체를 구분할 때 null 을 본다고 들었습니다.그래서 참조형 Long을 쓰는 구나 라고 생각을 정리했어요!! 헌데 코틀린으로 쓰신 코드에서는 Long타입을 선언하시고 0으로 초기화해주시는 이유가 궁금합니다!코틀린에서는 nullable하게 할순있지만 기본적으로 null이 불가능하다고 들었긴한데.. 조금 헷갈립니다!언어적인 부분에서 jpa가 다르게 동작하는것인지 아니면 제가 좀 미숙하게 이해한건지 궁금합니다!

제미니님 이커머스 강의와 프로젝트 코드들을 참고하면서 게시판을 만들어보고 있는 중입니다!현재는 게시물 정보만 페이징 방식으로 구현해놓았습니다.근데 게시글 목록을 보여줄 때 한 게시글 당조회수, 좋아요수, 댓글 수, 유저닉네임 등.. 표시가 되야해서 좀 헷갈립니다.  한 API에서 전부 조합해서 내려준다고하면페이징된 게시글 10개를 먼저 조회하고조회한 게시글의 ID를 기반으로 조회수와 좋아요를 따로 조회한 뒤에 같이 내려주는 방식이 좋을까요?  

안녕하세요. 이틀 전에 "[인프런] 제미니 개발실무 수강생 전용 Junie 이용권 증정"라는 제목으로 메일이 왔는데요.JetBrains의 후원으로, 강의에서 활용하는 AI 개발도구 Junie를 체험해 볼 수 있는 All Products Pack 3개월 이용권을 제공받기 위해 구글폼을 통해 신청하면 확인 후 쿠폰 코드를 발급해 주신다는 메일을 받았습니다.마감이 오늘까지라서 오늘 구글폼으로 들어가 봤더니 선착순 신청이 마감되어 조기 종료되었다고 뜨고 있습니다. 메일 내용으로 봤을 땐 선착순이라는 내용은 없었는데, 혹시 신청할 수 없는 걸까요?

제미니님 안녕하세요. 강의를 통해 각 개념 간의 응집성을 높이고, 불필요한 의존성을 줄여 격벽을 세우는 설계를 깊이 있게 연습하고 있습니다.강의에서 배운 원칙을 적용하여 '리뷰'나 '찜' 같은 개념들이 '상품' 개념을 단방향으로 참조하도록 구조를 잡고 있습니다. 하지만 실제 상품 목록 조회 기능을 구현하다 보니, 설계의 일관성을 유지하기 어려운 상황을 마주하게 되어 조언을 구하고자 합니다.개념 간 의존성의 역전: 목록 화면에서 '리뷰 수'나 '찜 수'를 함께 보여주거나, 이를 기준으로 상품을 정렬해야 하는 요구사항이 생겼습니다. 이 경우 상품 개념이 본래 몰라야 할 하위 개념(리뷰, 찜 등)의 상태를 알아야만 하는 상황이 발생합니다.API 구성의 어려움: 상세 페이지는 API를 잘게 나누어 클라이언트에서 합성함으로써 개념 간의 독립성을 지킬 수 있지만, 목록의 경우 수십 개의 상품에 대해 매번 각각의 리뷰 수 API를 호출하여 클라이언트가 매핑하는 방식은 어딘가 어색하고 성능과 구현 효율 면에서 의문이 듭니다.결국 조회를 위해 상품이 다시 리뷰나 찜을 알게 되면, 처음 설계한 개념 간의 단방향 참조 구조가 깨지거나 서로를 참조하는 순환 참조가 발생할 것 같아 우려됩니다.이처럼 개념 간의 격벽을 유지하려는 설계 원칙과, 여러 개념의 데이터가 한꺼번에 필요한 조회 요구사항이 충돌할 때 어떤 식으로 접근하는 것이 현명할까요? 원칙을 고수하며 우회할 방법이 있을지, 혹은 이런 조회 상황에서는 설계적 타협이 필요한 것인지 견해를 듣고 싶습니다.

안녕하세요, 선생님!좋은 강의 제공해주셔서 감사합니다. 덕분에 단순히 구현에만 집중하기보다, 설계와 개념에 대해 더 고민하면서 코드를 작성하게 되었습니다.섹션 2의 ‘개념 느끼기’ 부분에서 Product가 Product Category보다 더 상위의 개념이라고 말씀해주셨던 것으로 기억합니다. 저도 그렇게 이해했습니다.그런데 코드 구현 파트에서 Product와 Product Category 사이의 삭제 정책을 두 가지 예시로 설명해주셨는데, 그 부분에서 한 가지 궁금증이 생겼습니다.제 생각에는 개념적으로 Product가 더 상위 개념이라면, Product가 삭제될 때 Product Category도 함께 삭제되는 정책이 조금 더 자연스러운 흐름처럼 느껴졌습니다.이 부분에 대해 제가 개념을 잘못 이해한 것인지, 아니면 실무적인 관점에서 추가로 고려해야 할 부분이 있는지 궁금합니다.혹시 제가 놓치고 있는 관점이 있다면 조언 부탁드립니다!

안녕하세요 재미니님 유튜브로 접하게 되어 인프런 강의까지 듣게된 백엔드 개발자(5년) 입니다.현재 팀의 레거시 시스템을 고도화하는 레거시 시스템을 개편하는데 주력하고 있는 업무를 맡고 있습니다. 저희 회사는 규모가 적지 않고, 팀내에서 담당하는 시스템도 많은데 제 기준으로는 꽤나 보수적인 조직이라 ai 활용하는데 제약이 많은 편이라고 생각합니다. 금융권처럼 로컬 PC에서 외부망을 아예 차단하고 있지는 않지만, chat gpt, gemini 등 각종 llm을 제공하는 웹사이트는 차단이 되어있고 사내 자체 llm 만 사용할수 있는 환경입니다. 운이 좋게도(??) junie 는 아직 차단되어 있지 않아 많이 활용하고 있는데, 신규 구축이 아닌 기존 레거시 시스템을 분석하여 컨버전을 하는 과정에서 사용하기에 보안적으로 이슈가 될 부분이 있을까 싶어서 걱정이 많이 되는데, ai를 활용하면 생산성이 넘사벽으로 높아지는 환경에서 보수적으로는 보안 이슈를 걱정하는 팀원들이 있을경우, 재미니님은 어떤식으로 팀원들을 설득하실지, 보안 이슈가 없도록 방안은 어떻게 마련하고 계신지 궁금합니다.추가로 극단적인 예시긴 하지만, 비지니스 로직이 프로시저에 녹아져 있는경우, db 에 의존적으로 운영되고 있는 시스템(ex. 트리거, 서버 크론잡 스케줄링 등) 의 경우 ai를 활용하여 레거시를 최대한 개선하고 싶다면 어떤 전략을 활용할 수 있을지도 의견 주시면 감사하겠습니다.소중한 강의 제공해주셔서 감사합니다.

강의 잘 듣고 있는데요.같은 프로젝트에 대해 다수의 팀원이 개발한다고 가정 할 때현재의 AI를 사용하는 방식이 어디까지 유효할 지 재미니님의 생각이 궁금하여 의견 여쭙습니다.예를 들어 저는 AI를 적극 사용하고 싶을 때, 하지만 팀의 문화가 AI를 위와 같이 그닥 사용하지 않을 때, 강의 속에서 AI를 활용하는 방안을 어디까지 얘기하는게 좋을 지 등이 궁금합니다.제가 느낄 때, 위 강의 과정에서는 md 파일을 꾸준히 업데이트 하며, 히스토리를 쌓아가는 것 같아 의견을 여쭤봅니다.

제미니님 안녕하세요!30강 5분쯤에서 나온 결제 구조 관련해서 질문이 있습니다. 검증과 처리 책임을 모두 가지고 있던 PaymentManager를 Validator와 Processor로 분리한 의도는 이해했습니다.그리고 Validator와 Processor 각각에서 주문과 결제를 다시 조회하도록 구현하신 이유가 컴포넌트를 명확하게 분리하고 재사용성을 높이기 위함이라고 이해했습니다. 여기서 말씀해주신 “명확하다”는 표현이 PaymentService에서 비즈니스 흐름을 더 명확하게 드러내기 위한 설계 의도라고 이해해도 괜찮을까요? 한편으로는 다른 방식도 떠올랐는데, Validator에서 검증하면서 조회한 주문/결제 정보를 PaymentContext 같은 객체에 담아서 Processor.success로 전달하는 구조는 어떻게 생각하시는지 궁금합니다. 이런 방식이 책임 분리나 구조적인 측면에서 문제가 생길 여지가 있는지, 혹은 실제로는 어떤 트레이드오프가 있는지도 함께 알고 싶습니다!

안녕하세요 ! 결제 개념 쪽 강의 내용 중 궁금한 부분이 있어 질문 드립니다 ! 1. PaymentCreator를 별도 컴포넌트로 분리한 이유결제 개념에서 PaymentCreator를 별도의 컴포넌트로 추출하신 이유가 궁금합니다.결제 생성 또한 결제 개념을 처리하는 기능의 일부라고 생각해서, PaymentProcessor 내부에서 함께 처리할 수도 있지 않을까 생각했는데 Creator를 분리하신 설계 의도가 무엇인지 알고 궁금합니다!2. Manager vs Processor 네이밍 전략 기준다른 개념 영역에서는 Manager라는 네이밍을 사용하시다가결제 영역에서는 Processor라는 네이밍을 채택하신 이유가 궁금합니다.두 네이밍 사이에 역할적/의미적 차이를 두고 설계하신 것인지, 혹은 도메인 특성에 따른 네이밍 전략인지 궁금합니다 !

AI로 코드를 분석해보거나레거시의 수정 포인트를 느껴보거나 하는 부분은많이 와닿았는데요.AI 가 코드를 수정한 이후에코드를 비교해보는 영역에서 브랜치를 어떻게 관리하는게 좋을 지 의문이 들었습니다.AI 가 다수의 코드를 변경하고 있는데, 실제 실무에서는 한 꺼번 에 코드를 바꿔버리면 diff가 너무 많아서 개발시 우려되는 부분이 많이 생깁니다.gpt에 물어보면 ai/product-draft 와 같이 실험용 브랜치에서 작업 이후에 선별하여 수정하라는 답변을 받았는데요.아직 섹션3을 수강하고 있어서, 이른 질문일지 모르지만 해당 사항 관련하여 실무적인 관점에서 실제로 어떻게 하는게 좋은 방법일 지 조언 한 번 부탁드립니다.