안녕하세요!강의를 보던 중 ReviewService의 트랜잭션 처리에 대해 궁금한 점이 있어 질문드립니다. addReview 함수에서 리뷰를 저장하는 add()와 포인트를 적립하는 earn() 두개의 중요한 함수를 사용하고 있는데, 이는 각각 별도의 트랜잭션으로 처리되어 리뷰는 저장되고 포인트는 적립되지 않는 문제가 발생할 수 있을 것 같습니다.  현재 설계에서 addReview()에 @Transactional을 붙이지 않은 특별한 이유가 있으신지 궁금합니다. 혹은 만약 의도적으로 별도 트랜잭션으로 분리한 것이라면 그 이유가 궁금합니다. 항상 감사합니다.

안녕하세요, 제미니님.유투브 및 인프런 강의 잘 시청하고 있습니다 :) 인프콘 2024에서 '지속 성장 가능한 설계를 만들어가는 방법' 이라는 주제로 발표해주신 내용이 무척 공감이 되었고, 제미니님 유투브를 찾아봤다가 강의까지 수강하게 되었습니다 이번 강의 내용은 아니지만 인프콘 영상에서 말씀해주신 개념인 '개념' 과 '격벽'을 구체적으로 실무에서 어떻게 사용하면 좋을지를 여쭤보고자 인프런 질문을 통해서 글을 올리게 되었습니다. 편의상 신규 프로젝트를 진행한다고 가정했을때,요구사항을 분석하고 도메인을 구성하는 여러 '개념'들을 나열한다.나열된 '개념'들의 급(1급, 2급, 3급 ..) 을 나눠보고 그룹화 하면서 '격벽'으로 분리한다.'격벽'으로 분리된 그룹이 어떤 개념을 통해서 연결될지 방화벽으로 동작할 개념을 생각해본다. 이는 개념간 무분별한 참조를 막기 위함이다.'개념'들과 '격벽'들을 기반으로 일단 코드로 구현부터 해본다. ('설계를 하지 말고 구현을 먼저' 하는 포인트는 이것)구현하면서 또는 운영하면서 더 나누거나 신규로 추가할 개념이 있다면 반영한다. 결과적으로 설계를 하지 않고 구현을 먼저 하고, 구현 하는 과정이나 운영 하는 과정에서 최적화 시킨다. 이것이 곧 최적의 설계로 나아가는 방향이 된다. (질문) 제가 제미니님이 말씀하신 '개념'과 '격벽'을 잘 이해한 것이 맞을까요? 실무에서 위 흐름대로 적용하면 제미니님이 강조하신 내용에 기반한 작업이 될 수 있을까요? 실무에서 실제로 말씀해주신 내용을 적용해보고 싶은데 구체적으로 어떤식으로 적용하면 될 지 몰라서 제가 이해한 내용을 바탕으로 작성을 해보았습니다. 틀린 부분이 있다면 피드백을 부탁드리고 싶습니다 :) 긴 글 읽어주셔서 감사합니다~

안녕하세요 시간날 때 틈틈히 보다가 어느새 막바지에 다다랐네요! 타임베이스 정산 배치가 실패했을 때 궁금한점이 있습니다. 우선 현재는 시간 대별로 오전 1시, 4시, 9시로 배치가 나눠져있는데이 상황에서 강의에서도 설명하셨듯이 오전 1시 배치가 오전 4시 30분에 끝나서 오전 4시의 배치가 에러가 뱉는 상황에 대해 문제를 해결하는 방법들이 궁금합니다! 우선 제가 생각한 방법들은 다음과 같습니다.1. 이벤트 기반 이벤트 기반으로 각 단계가 완료되면 바로 다름 배치 단계로 넘어가는 방식입니다.하지만 이 방법은 이미 기존 인프라와 코드를 변경해야하고 정산 시간이 고정 된다는 요구사항이 있다고도 보여 현재 요구사항에는 적절하진 않은 것 같습니다.  2. 각 배치마다 전 단계 완료 여부 상태를 확인오전 4시, 오전 9시 배치가 이전 단계의 배치 중 실패한 배치 이력이 있는지 확인하는 방법입니다.현재 스케줄링 방식으로는 이를 위해 별도의 배치 기록 테이블을 만들어서 배치 이력 관리를 추가합니다.오전 4시, 오전 9시에 해당 정산 날짜에 대해 실패한 이전 배치 단계 이력이 있다면 성공할 때 까지 N번 재시도 합니다.정산의 즉시성이 필요하다면 N번 재시도 후 실패했을 때 해당 배치 단계를 에러 상태로 처리하고,에러 로깅과 알림을 전송합니다.다음 배치 단계는 정산 날짜에 해당하는 이전 배치 이력이 에러 상태로 남아 있다면 실행하지 않습니다. 현재 요구사항에서는 수동으로 처리할 부분은 최대한 제거하는 2번 방식을 사용할 수 있을 것 같습니다.제가 배치 관리에 대해 잘 이해하고 있는지 모르겠어서 생각한 방법에 대해서 재민님은 어떻게 생각하시는지 궁금합니다.! 항상 잘 보고 있습니다 감사합니다!  

선생님, "프롤로그에서 ..." 오류 관련해 직전 질문에 대한 추가 질문입니다.지금의 상황에서 수평 관련 제약 조건이 추가되지 않는다면, 왜 문제의 오류가 발생하는 것인지요?지금의 경우 이처럼 constraintLayout을 써서 복잡하게 제약 조건이 필요하다면, 이때 차라리 그 전체 layout으로서 Linearlayout을 사용하는 것이 더 간단하지 않을까요?

"4. 강의 PDF 자료 및 프로젝트"에서 프로젝트 소스는 있는데 강의PDF는 안 보이네요..어디에서 강의 PDF를 찾을 수 있을까요?

안녕하세요, 강사님. 취소 - 코드느끼기 수업의 5:00~ 부분부터'결제', '취소'의 스키마를 분리하여 레코드를 immutable하게 다루는 상황의 예시로 결제 취소 상황을 설명하셨는데 어떤 부분에서 유리한건지 모르겠습니다. 7일 전 주문을 30일 후에 취소함'취소'를 '결제'의 상태로 반영할 때'결제'의 상태를 '취소'상태로 변경 - 레코드 수정 시각 갱신취소된 '결제' 조회 시 레코드 수정 시각을 이용해야 함'취소'를 스키마로 관리할 때새로운 '취소' 레코드 추가제가 이해한 상황은 '취소된 결제를 결제 id 없이 취소 시각으로 조회해야한다'는 것입니다.취소된 결제를 결제 id 대신 취소 시각으로 찾는 경우는 어떤 상황인지, 조회를 위해 어느정도 취소시각의 범위를 특정할 수 있는 데이터가 존재할텐데 데이터가 결제 id와 분리되어 존재하는 이유가 무엇인가요?'취소'스키마가 따로 존재해서 결제 취소가 레코드로 쌓일 때, 취소 시각으로 찾는다면 무엇이 다른건지 모르겠습니다.'규모적으로 선택하라. 테이블이 적고 테이블 로우가 적고 접근 범위 자체를 줄일 수 있고, 이런 장점으로 보면 페이먼트 테이블을 만들어도 되는데요' 라고 말씀하신 부분도 모르겠습니다!수업 진행하시면서 1) 각 개념의 레코드가 자신의 영역 안의 맥락으로만 수정된다, 2) '결제'의 레코드는 많고, '취소'의 레코드는 적으므로 취소 일자로 조회하는 속도 차이가 난다고 하시는 것은 이해했습니다만 앞서서 예시로 들어주신 부분은 잘 모르겠네요. 감사합니다.

아직 MSA 경험이 없다보니 질문을 드려봅니다.메시지에 관련된 Entity를 공통 모듈로 뺀다고 하셨는데용Lecture_1 라는 프로젝트, Lecture_2 라는 프로젝트가 있다고 가정을 했을 때'공통 모듈' 이라는걸 별도의 프로젝트로 구성한다는 말씀이실까요?아니면 아래와 같이 프로젝트 root외에 모듈을 별도로 잡아서 한다는 말씀이실까영?rootProject.name = 'Lecture_2' include 'common' <-- 공통 모듈?rootProject.name = 'Lecture_2' include 'common' <-- 공통 모듈?아, 그리고 최근에는 MSA에 대한 단점이 명확해지고 있어서 Modular Monolithic 아키텍처도 생겨나고 있는데 강사님께서는 이 부분에 대해서 어떻게 생각하시는지도 궁금합니다!

선생님, 강의 잘 듣고 있습니다. 그런데 영탁 등등의 노래 리사이클러뷰 앱을 만들 때, 다음까지는 잘 됩니다.그런데 이후 <TextView> 부분에 background를 첨가하거나 텍스트를 바꾸기만 해도 계속 위의 제목에서 보인 오류가 뜨고, 이후 다른 fragment에서도 마찬가지 오류가 뜹니다.왜 그런 것이며, 어떻게 해결해야 할지요? 현재 최신 버전이 Otter를 사용하고 있습니다.<?xml version="1.0" encoding="utf-8"?> <androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context=".Singer1Fragment"> <TextView android:text="영탁 노래 리스트" android:textColor="@color/black" android:gravity="center" android:layout_margin="10dp" android:textSize="30sp" android:layout_width="match_parent" android:layout_height="wrap_content" app:layout_constraintTop_toTopOf="parent" /> <androidx.recyclerview.widget.RecyclerView android:id="@+id/singRV" android:layout_marginTop="50dp" android:layout_marginBottom="80dp" android:layout_width="match_parent" android:layout_height="match_parent"/> <!-- TODO: Update blank fragment layout --> <LinearLayout android:layout_width="match_parent" android:layout_height="80dp" app:layout_constraintBottom_toBottomOf="parent"> <ImageView android:id="@+id/image1" android:scaleType="fitXY" android:layout_weight="1" android:src="@drawable/photo1" android:layout_width="match_parent" android:layout_height="match_parent"/> <ImageView android:id="@+id/image2" android:scaleType="fitXY" android:layout_weight="1" android:src="@drawable/photo2" android:layout_width="match_parent" android:layout_height="match_parent"/> <ImageView android:id="@+id/image3" android:scaleType="fitXY" android:layout_weight="1" android:src="@drawable/photo3" android:layout_width="match_parent" android:layout_height="match_parent"/> </LinearLayout> </androidx.constraintlayout.widget.ConstraintLayout>

안녕하세요 강사님 그 정적 팩토리 매서드는 강의에서 data class dto 측에 써 주셨는데 현업에서는 주로 dto에 쓰는 게 컨벤션인 가요?

디바이스 선택시 Chrome(web)과 저의 실물 핸드폰 연결해서 했더니 안드로이드 스튜디오 코드는 잘 돌아갑니다.하지만 BoardViewModel.dart 코드에서 설정한 url그대로 따라 쳤는데swagger ui에서계속 화면처럼 response body가 비어있습니다.. 계속나와서 혹시 전체 소스코드 공유 안될까요??

안녕하세요! 강의를 듣다가 궁금한 것이 생겨서 질문 남깁니다.PointBalanceEntity에 낙관적 락을 추가해서 유저의 어뷰징을 방지한다고 하셨는데, 비관적 락이 아니라 낙관적 락을 사용하는 이유가 있을까요?포인트 적립이나 사용에 있어서는 충돌 가능성이 많지 않아서 낙관적 락만으로 해결 가능한 것인지, 아니면 비관적 락보다 성능이 더 좋아서 그런 것인지 궁금합니다.물론 말씀하신대로 상황마다 모두 다르겠지만, 대체로 어느 정도 규모가 있는 서비스에서도 낙관적 락만으로 해결이 되는 것인지도 궁금합니다.

안녕하세요 좋은 강의 잘 들었습니다~!강의를 모두 듣고 제공해주신 프로젝트를 쭉 확인하고 궁금한 점이 생겨서 문의를 남겨봅니다저는 실무에서 도메인 모델과 엔티티 모델을 구분하지 않고도메인 모델에 JPA관련 어노테이션을 모두 허용한 상태로 개발해왔습니다물론 구분해서 개발해본적도 있었지만컬럼 변경 등 다양한 변경사항에 대응할 때마다 도메인 모델과 엔티티모델을 둘 다 확인하고 변경해야하는 번거러움?이 생겼던거 같아서 클래스가 좀 지저분해지더라도 도메인 모델 하나로 개발하고 테스트 코드를 작성해왔었습니다이번 강의에서 사용된 프로젝트의 경우모듈과 패키지가 나눠져있어서 도메인 모델과 엔티티 모델이 분리되어있는듯 보이지만 제가 사용했던 구조와는 다른점이 있었습니다..!도메인 모델은 강의에서 말씀하신 개념과 격벽그리고 행동에 대해 적절하게 표현하기위한 객체이지만 핵심 비즈니스 로직을 모두 포함하고 있는게 아니라 대부분 조회된 데이터를 개념에 맞게 변경하는 DTO? 역할을 하는것 같고 상태변경에 대한 로직은 엔티티에 구현하고 service 레이어에서 호출하는 방식으로 보여집니다그렇지만 처음 보는 코드가 잘 읽힐정도로 충분히 설득력있는 구조라고 생각이 듭니다..다만 테스트 코드가 있어야만 그 설득력이 완벽해질것 같다는 생각이 들었습니다그래서 해당 프로젝트 구조를 더 이해하고 학습하기위해 테스트 코드를 작성해보려고 합니다만약 저라면 ~Entity에 작성되어있는 상태변경에 대한 테스트 코드와 ~Service, ~Handler, ~Manager 등에 작성된 로직에 대한 테스크 코드를 작성할 것 같은데강사님은 이러한 구조에서 테스트 코드를 어디까지 작성하시는지 또는 어떻게 접근하시는지 궁금합니다~!

안녕하세요. 수강기간이 내년 1월까지인데 추가 금액을 지불 할 생각도 있는데 연장이 가능할까요??몸이 안좋아서 그동안 듣지를 못했습니다.알려주시면 감사하겠습니다..

안녕하세요, 강사님. 질문 주제:리뷰의 개념도에서 "Product" 개념이 표현되지 않은 이유로 "리뷰 대상을 범용적으로 지정할 수 있도록 설계"했다는 점을 짚어주셨는데 저는 "리뷰가 상품 대신 주문에 의존하기 때문"이라 생각합니다. QnA - 개념 정리 수업을 제 식대로 정리한 내용입니다.개념도에 어떤 개념을 표현할지 기준을 세우자.코드/스키마 관점보다 개념적/비즈니스적 관점에서 바라보자.개념도는 운영/기획팀 등 여러 구성원과 소통하기 위한 수단. 코드/스키마 관점으로는 의사소통 어려움.'모든 개념이 클래스로 대응되지 않고, 모든 클래스가 개념으로 대응되지 않는다'는 점에서도 코드/스키마 관점으로 개념도를 그리는 것은 어렵다고 생각합니다.위의 내용을 기반으로 생각해보니 비즈니스에서 상품에 대해 리뷰가 작성되는데 리뷰 개념과 상품 개념이 연관이 없다고 생각하니 어색하게 느껴집니다. 기획팀 등 누군가와 대화를 가정하여 "상품에 리뷰를 쓸텐데 왜 리뷰 개념이 상품 개념과 연결되지 않나요?"라는 질문을 받았을 때 "리뷰 대상을 범용적으로 지정하도록 설계해 상품 개념을 직접 의존하지 않기 때문"이라 대답하면 코드/스키마 관점의 대답이라 생각됩니다. 그래서 저는 리뷰의 대상이 "상품"이 아닌 "구매한 상품"이기 때문에 "Review"가 "Product" 가 아닌 "OrderItem"을 의존하여 개념도에 "Product"가 표현되지 않고 "Order"가 표현되었다고 생각합니다.이렇게 생각하면 제가 느꼈던 어색함이 해소되는 것 같습니다.비즈니스적으로 리뷰의 대상은 상품이니 개념적으로 리뷰와 상품은 연관되어 있지 않는가?리뷰는 구체적으로 '상품' 대신 '구매한 상품'에 대해 작성하므로 리뷰는 "OrderItem"에 의존하고, 개념도에는 그 상위 개념인 "Order"에 의존하도록 표현함. ("Review"는 "Order"를 거쳐 "Product"와 간접적으로 연결된다는 관점)'리뷰 대상의 범용적 설계'는 코드/스키마 관점운영/기획팀에게 리뷰는 "구매한 제품"에만 작성할 수 있으니 "Product" 대신 "Order"에 의존한다고 대답함. 제 생각에 대해 강사님의 견해가 궁금합니다.감사합니다.

안녕하세요 강사님 취준생으로써 강의 들으면서 궁금한 점 질문 드립니다.1.CustomRepository형식 과 Impl 형식이 보통 어떨때 자주 쓰이는 지 궁금해서 질문 드립니다. 2.JPA 에서 작성한 것들을 Querydsl 로 바꿀때가 그럼 ByXxx 에서 조인조건이 두개이상 들어가면 무조건 Querydsl 자바코드로 바꾸어 주는 게 좋을까요?

안녕하세요 제미니님, 유튜브부터 잘 보고 있는 수강생입니다. 항상 좋은 영상과 강의 감사합니다. 다름이 아니고 블로그에 작성해주신 글 [지속 성장 가능한 소프트웨어를 만들어가는 방법] 중 소프트웨어 레이어에 대해 언급을 해주셨는데, 해당 강의의 프로젝트가 이와 유사한 구조인 듯합니다. 질문:제미니님은 현업에 계실 때에 비즈니스 레이어(Service)에서 도구 레이어(Finder, Handler,..)를 호출하는 흐름을 어느 정도까지 강제하셨는지가 궁금합니다.팀 단위의 개발에선 컨벤션이 어느정도 정해져있는게 개발 생산성에 유리하지 않을까 하는 생각에 질문 남겨봅니다. 답변 미리 감사드립니다.🙇‍♂

찜한 목록 조회나 찜하기 등에서 궁금한 점이 생겼는데요. 찜한 목록 자체가 찜한 상품 목록일텐데 그렇다면 찜 목록 조회 시 찜한 "상품" 데이터 목록을 응답해주어야 하는게 아닌가요? 상품의 아이디만 반환해주고 클라이언트에서는 해당 상품 id 목록으로 상품 목록을 재 조회하는 등의 방식으로 설계하신건지... 궁금합니다. 또 찜하기에서는 상품이 실제 존재하는 상품인지에 대한 검증이 없는 것 같은데 이 내용은 상품의 개념이기에 표현되지 않은 것일까요? 실제 존재하는 상품에 대해서만 찜하기가 가능하다. 라는 내용또한 개념으로 작용할 수 있는 것일까요?

안녕하세요!~! 이건 주문 뿐 아니라 다양한 개념에서도 할 수 있는 질문인 것 같은데요~! OrderController 에서 요청을 처리하기 위해 어쩔 수 없이 cartService 를 알고 의존하고 있는데 (개념격벽에서는 차단), 개념간 격벽의 관점에서 OrderController는 order 에 관한 개념이 아닌 것인지 궁금합니다.Controller 단계에서 여러 Service를 조합하는 코드 스타일로 작성하셨다고 했는데, 만약 Controller 에서는 깔끔한 하나의 OrderFacade(?) 의 메서드만 호출하고 Facade 안에서 여러 서비스를 조합해 기능을 수행한다고 했을 때, 이 OrderFacade 는 Order 개념으로 치지 않는 것인지도 궁금해용.NewOrder 는 Cart 에서 cart.toNewOrder() 로 바로 만들고 있잖아요?결론적으로 Cart 가 Order 를 의존하는 방향이 되어 버리는데 혹시 Cart 가 Order 를 의존하는 것을 의도하신 것인지 궁금합니다.개념 정리 강의에서 그려주신 그림을 보면Product <-- OrderProduct <-- Cart이렇게 Product 에 Order 와 Cart 가 의존하고 있는 모습인데, 위에 제가 말씀드린 로직에서는Order <-- Cart의존 화살표도 추가해야 맞을 것 같은데 혹시 제가 잘못 이해한 것인지 궁금합니다..!추가로, Product <-- OrderProduct <-- Cart이 의존 방향을 그대로 지키려면,,cart.toProductWithQuantitys() 로 카트를 프로덕트로 변환 후에NewOrder.fromProductWithQuantitys() 로 프로덕트를 오더로 생성하는 것이 의존 방향이 깔끔하게 맞지 않나 생각이 들어용, 혹시 이건 어떻게 생각하시는지 궁금합니다.제 생각에는,, 이렇게 복잡해질 바에야 Order 에서 Product 와 함께 Cart도 같이 알고 있는 것이 좀 더 간단해지지 않을까 하네용.. (지금 코드 처럼)  현업에서 기존 짜파게티 코드 위에서 개발하다 보니,, 의존 방향에 크게 신경쓰지 않고 직관으로만 개발해왔는데요,, (from~~() , to~~() 남발..ㅎㅎ)제미니님 강의를 들으면서 안일하게 생각하고 있던 부분을 다시 한 번 생각해보게 된 것 같습니다.항상 감사해요~~

상품 목록 조회하는 부분이 지금은 응답과 테이블까지 필드가 모두 같은 형태라 간단한 것 같은데, 함께 보여줘야 할 데이터가 더 많은 경우에는 어떻게 처리하시나요?예를 들어 상품 카드위에 세일 정보가 있을 수도 있고, 해당 상품이 현재까지 팔린 갯수를 카드 위에 표시해야 할 수도 있을 것 같습니다.아래는 제가 생각해본 방안입니다.서비스 컬렉션 조회 함수에서 함께 조립단점: 단일 객체가 아닌 컬렉션이기에 데이터 매핑과 조립을 위한 로직이 굉장히 길어질 수 있다. (비즈니스 로직이 아닌 느낌), 또한 개념객체를 반환하는 것이 아닌 조립된 객체를 반환하기에 화면에 표시되어야 할 부가 데이터가 변할때마다 매번 다른 객체를 만들고 반환해주어야 한다.컨트롤러에서 각각 조회 후 조립단점: 컨트롤러에서 조회 후 조립을 한다면 ~ Service 등 부가 데이터를 조회하기 위한 함수가 있을 것이고, 이 함수 또한 반환하는 객체가 있을 것인데 그럼 이때 부가 데이터를 담고 반환하는 객체 또한 개념 객체로 생각해야 할까? (화면 구성에 따라 달라지는 데이터인데 내부 개념으로 정의해도 맞는 것일까?), 개념 객체가 아니라면, Service 레이어에 위치해도 되는 것일까?적다보니 굉장히 길어진 느낌이네요... 강사님은 어떤 생각이신지 궁금합니다!긴 글 읽어주셔셔 감사드립니다!