안녕하세요 유투브를 쭉 챙겨보다 강의를 내셔서 바로 달려온 구독자 중 한명입니다 ! 다름이 아니라 섹션 2의 개념 정리 에서 개념도의 격벽에 대한 내용을 코드로는 어떤식으로 표현되는지를 좀더 확실히 이해하고 싶어 질문드립니다. 현재 상품 과 카테고리 테이블 구조는 N : N 으로 되어있고 ProductCategory 는 이 다대다 관계를 연결하는 매핑 테이블 로 이해했습니다. 그렇다면 상품 과 카테고리 는 서로가 서로를 알지 못하는 격벽으로 나눠져있으며 모든건 이 매핑 테이블 인 ProductCategory 로 이뤄지고 상품과 카테고리의 정보를 가져오기 위해서는 두 개념은 서로를 알지 못하니 ProductFinder 에서 ProductCategoryRepository 를 사용해 Category 를 얻은 후 Product 를 반환한다. 가 제가 이해한 격벽을 구현한 코드가 맞을까요 ? 또 이 격벽을 위한 코드에서 조인을 사용하지 않는 이유가 궁금했습니다. RDBMS과 NoSQL의 차이점 하나가 JOIN으로 알고 있는데 JOIN을 사용하지 않고 개별적으로 접근한다는 점이 조금 새롭게 다가왔거든요. 기존에 다른 수강생 분들의 QA를 종합해서 정리했을 때는 다음과 같이 정리됐습니다. 무적의 한방 쿼리 사용을 지양 (쿼리가 점점더 비대해짐) 조인을 사용하지 않음으로써 다양한 조합(재사용)이 가능 복잡한 쿼리문을 들여다보지 않고 각 쿼리문들을 통해 로직의 흐름을 파악할 수 있다??? 제가 이해한 내용이 맞을까요?? 항상 잘 보고있습니다! 감사합니다!
킬구형 공부중에 문득 궁금해진건데 혹시 스프링배치도 AOP를 적극적으로 활용해? 스프링배치도 기본 구조는 스프링이랑 같아서 AOP를 쓸 수는 있을 것 같은데 실제로 활용을 하는지 궁금하네 쉽게 쓰기에는 @Transaction 어노테이션도 뭔가 활용성이 있을 것 같고.. API 리퀘스트 실패 시 자동으로 재처리 하는 AOP 기능을 만들어보기도 했는데 FaultTolerance 관련으로 비슷하게 활용할 수도 있을 것 같고.. 아무튼 스프링배치에서 AOP를 적극적으로 활용하는지 궁금해
☠ 질문 가이드 ☠ " 시스템 종결자의 지령이다. 질문하기 전에 이 규칙들을 숙지하도록. " 1. 코드 실행에 문제가 있다고? 전체 코드를 보여줘라. 단편적인 에러 메시지만으로는 아무것도 알 수 없다. 실행 환경도 알려달라. JDK 버전, 스프링 버전 등을 함께. 2. 오타를 발견했나? 즉시 제보하도록. 자네같은 날카로운 눈을 가진 동료가 필요하다. 3. 질문은 자유롭게 "이런 걸 물어봐도 될까요?" 같은 소심한 멘트는 불필요하다. 궁금한 건 바로 물어봐라. 배치 시스템에 소심한 건 없다. 4. 검색은 기본 비슷한 질문이 있는지 먼저 확인하도록. 하지만 이해가 안 된다면? 주저하지 말고 추가 질문해라. GPT가 거짓말친다고? 나에게로 오라. 💀 5. 서로 존중하라 여기는 모두가 시스템을 지배하고자 하는 동료들이다. 서로를 이해하고 돕는 문화를 만들어가자. ⛔ 인프런 서비스 자체에 대한 문의는 1:1 문의하기로. 💀 그쪽 서버는 막강한 CTO가 있어 건드리지 않는 게 좋을 거다 💀 - KILL-9 올림 P.S. 존댓말로 질문하면 rm -rf를 시전한다. 편하게 물어보도록. 강의에서 놓친 부분이나 더 보충하면 좋을 내용도 자유롭게 제보하라. 너희의 피드백이 이 강의를 더 강력하게 만든다. 🔥 시스템을 함께 진화시켜 나가자. 🔥 킬구형님 안녕하세요! (그래도 선생님이신데 반말하기엔 좀 그런것 같아서 존댓말로 하겠습니다..!) 먼저 좋은 강의 감사드립니다. 사실 구매한지는 좀 되었는데, 지난 1주일동안 Batch와 스케쥴러의 차이점, 왜 이런 어노테이션을 사용하는지부터, 왜 이런 환경설정을 해야하는지, Framework와 Boot의 동작차이점은 무엇인지 세세하게 먼저 이해하는데 집중하다보니 힘이 많이 들었는데 0장 만으로도 상당히 많은 기본기가 쌓인 것을 느낄 수 있었습니다(무엇을 모르고있었고 무엇을 알아야하는지 등). 배치가 막연하게 느껴졌는데, 아직 극초반이지만 자신감이 생기고 있습니다. 감사드립니다! 1장에 들어가기전에 앞서, 조금이라도 더 실무에 가까운, 가깝지 않더라도 유지보수가 간편하고 알아보기 쉽게 체계를 구성해보고자, 형님께서는 실무적으로 배치 프로젝트를 어떻게 구성하시는지 질문드리고자 합니다. 각파일들의 디렉토리 위치가 없는데 임의적으로 해야하나요? - 인프런 | 커뮤니티 질문&답변 위 질문에서 형님께서는 상관이 없다고는 하셨는데, 그래도 실무에서는 어떻게 구성하시는지 궁금해서 질문드리게 되었습니다! 그리고 0장에서도 간단한 1개의 Job도 5개의 Step으로 이루어져 있는데, 위 질문의 AI답변처럼 1개의 Config 책임으로 두기보다는, Job - Step으로 책임을 분리하여 두는 것이 편할 것 같은데, 이게 실무에서도 실제로 이런 방향으로 관리가 이루어지는지 궁금합니다! 답변내용 참고하면서 본격적으로 1장부터 프로젝트를 구성해보고자 합니다. 감사합니다!
제가 느끼기엔 SettlementTargetSummary는 개념 객체에 좀 더 가까운 것 같은데, 혹시 db core 모듈에 위치해 있는 특별한 이유가 있을까요? 코드 자체도 @Entity 어노테이션이 붙지 않은 걸 보니 테이블로 관리하지 않는 것 같은데 여기에 두신 이유가 궁금합니다! 감사합니다.
CommonService 클래스 부분에서 이 코드 테스트를 하며 생각을 해봤는데요 EX) 루트 댓글 A(논리삭제) ㄴ 댓글 B ㄴ 대댓글 C 상황인 경우에서 B를 삭제했을 경우에 논리 삭제 되어있던 루트 댓글A도 삭제가 되면서 루트 댓글 A(물리삭제) ㄴ 댓글 B(물리삭제) ㄴ 대댓글 C 이런 상황으로 된다면 대댓글 C는 물리삭제 된 루트 댓글A를 parent로 가지는 고아 댓글이 되어버리는 것은 아닌가 궁금해서요!! 깔끔하게 딥한 강의 너무 잘 듣고 있어요!! 감사합니다 :)
안녕하세요. 정말 재밌게 수강중입니다. 다름이 아니라 데이터 검증 책임에 대해서 궁금한게 있습니다. 저는 사용자에 의해 넘겨받은 데이터를 Controller 에서는 값의 존재여부와 타입 정도만 확인하고 실제로 비즈니스 레이어에서 사용될 때 검증하는 것을 선호하는데, 강의에서는 Request(DTO) 객체에서 toContent() 함수를 호출하면서 검증하더라구요. 특별히 Request 에 위치시킨 이유가 있을까요? 관점이 궁금합니다. fun toContent(): QuestionContent { if (title.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST) if (title.length > 100) throw CoreException(ErrorType.INVALID_REQUEST) if (content.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST) return QuestionContent(title = title, content = content,) } 해당 로직이 아래 방식으로 들어가는게 책임이 맞지 않을까? 라는 생각입니다. data class QuestionContent( val title: String, val content: String, ) { init { if (title.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST) if (title.length > 100) throw CoreException(ErrorType.INVALID_REQUEST) if (content.isEmpty()) throw CoreException(ErrorType.INVALID_REQUEST) } }
안녕하세요. 정말정말 왕초보인 수강생입니다. 강의 대로 진행중인데 어찌해야 할지 몰라 문의드립니다. 11강 프로젝트 생성의 3:54에서 부터(cmd -> spring shell -> $ init) 저는 아래와 같이 에러메세지가 뜹니다. 이걸 어떻게 해결해야 할지 감 못 잡고 있습니다. ㅜㅜ -- Using service at https://start.spring.io Failed to retrieve metadata from service at 'https://start.spring.io' (PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target) -- (현재 설치환경) 스프링 부트 2.7.18버전을 설치했고 IntelliJ java는 21버전 설치 spring initializr에서 스프링부트 3.5.6 버전으로 템플릿 받아둔 상태입니다. 환경변수 JAVA_HOME, SpringBoot_Home 셋팅해두었습니다.
킬구형 1장 - 작전3에서 아래와 같이 얘기한 부분에 대해 궁금한게 있어. '리스너는 감시와 통제만 담당한다. 실제 시스템 제거 로직( 비즈니스 로직 )은 분리하라. 리스너가 너무 많은 일을 하면 유지보수가 어려워지고 시스템 동작을 파악하기 힘들어진다' 청크 기반 배치 잡이라고 하고 A라는 테이블에서 데이터를 읽어와서 B라는 테이블에 데이터를 삽입하는데 B 테이블에 데이터가 없다면 삽입, 있다면 수정하는 로직이 있어. 이 과정들이 모두 끝나고 마지막으로 B 테이블에 수정 날짜 컬럼이 잡 시작 시간보다 이르다면 A 테이블에 데이터가 없으므로 B 테이블에서 이러한 데이터들을 삭제하려는 로직을 넣는다고 했을 때 아래 궁금증들이 있어. 1. 위 얘기를 토대로 생각해보면 삭제 로직은 청크 기반 스텝 이후 태스크릿과 같은 다음 스텝으로 넣는게 좋은 것 같은데, 실무에서는 해당 잡 전용 리스너를 하나 추가로 만들어서 afterJob 메서드에 배치 상태가 COMPLETED인 경우에 삭제 로직을 실행하도록 하는 방식은 지양하는 편인거야? 전용 리스너를 만들어서 사용하는 경우도 있어? 만약 리스너에 삭제 로직을 넣는다고 했을 때 리스너에서 데이터 삭제 과정 중 오류가 발생한 경우에는 잡이 실패 상태로 종료되는거지? 2번과 같은 맥락인데 리스너에 삭제 로직을 넣는 경우 트랜잭션이 필요할텐데 리스너는 트랜잭션 범위가 어떻게 돼? 스텝에서는 청크 범위, 태스크릿의 반복 범위라고 본 걸로 기억하는데 리스너는 트랜잭션 설정 자체가 안되는건지 리스너 범위 내부에서만 설정되는건지 궁금해.
안녕하세요. 상품 상세조회 섹션을 보고 궁금한 점이 생겨 질문을 드립니다 ! 평소에는 개념간 격벽을 신경쓰지만 조회 시에는 지키기가 쉽지 않더라고요. 특히 list 조회인데 다른 개념이 있어서 조회 + in query + 조립 등을 하면 너무 과한가..? 싶은 생각이 가끔 듭니다. 제가 생각하는 방법과 트레이드 오프입니다. 개념간 격벽을 유지하고, 쿼리를 분리 아무래도 복잡해지는 구현 DB 커넥션을 위한 오버헤드 증가 팀원의 공감을 생각보다 얻기 힘듦(사실 저부터 확신이 없는...) 조회의 경우 느슨한 규정 화면 요구사항에 따라 변하는 쿼리 재사용성 x 주체가 모호함 점점 쌓이는 비슷한 쿼리와 projection dto들 거의 혼자 백엔드 개발을 진행하다보니 이런 고민에 대해 선택을 내리기 참 어렵네요 ㅎㅎ.. 제미니님은 어떤식으로 선택하시는지 궁금합니다 ! 감사합니다.
안녕하세요. 강의내용중 payment는 자기가 취소되어있는지 모르지만 대신 cancel은 payment를 사용한다고 말씀하시는데 이게 어떤의미인지 잘 이해가 되지 않습니다. 상태반영은 order쪽에 하는데 cancel이 payment를 사용한다?? 이게 어떤의미일까요??
안녕하세요. 저였으면 찜추가 찜삭제 API 를 나누는걸로도 방지할 수 있다고 생각해요.말씀해주신것처럼 컨트롤러에서 분기문 들어가는게 좀 어색한것같아서요! 이런 방식도 가능할까요? 뭔가 저는 Restful 관점에서도 이게 자연스러우니 이렇게 해결하실 것 같았는데 언급이 없으셔서 문제가 있을수도있나 싶어서 여쭈어봅니다!
안녕하세요! 현업에서 도메인(core) 모듈에 enum 들도 같이 두고, 타입 판단 로직 등 도메인 비즈니스 로직을 enum 클래스 내부에도 응집시켜 놓는 편인데요~ (bo 객체 클래스가 따로 존재하지 않거나 객체 클래스 보다는 enum 클래스에서 판단하는 것이 역할이 더 맞다고 생각되는 경우 ex enum 생성 static 메서드 등) 현재 예시 프로젝트의 구조에서는 core-enum이 core-api 의 도메인 로직 등을 의존하지 않고 완전 독립적으로 존재하기 때문에 enum class에는 비즈니스 로직이 존재하면 안된다는 것을 의도하신 것 같아 질문드립니다! enum 은 로직에서 아예 제외시키는 편이신가요? 그렇다면 이유가 궁금합니다.
coupon 데이터 처리시 !! 연산자 처리하는 부분에 질문이 있습니다. 논리적으로 현재 기획상으로는 null 일리 없음. -> !! 연산자를 사용 이 상황으로 코드를 이해하긴 했어요. 하지만, 이러한 방식은 일종의 암묵지라서 버그가 발생할 여지가 있어보이는데요. 특히 쿠폰처럼 사람이 개입하는 경우에 어드민에서 상태를 변경하는 경우 기존의 전제가 성립하지 않을 때가 있잖아요. (쿠폰을 비활성화 한다거나) 이런 경우 몇가지 선택지가 있을거 같아요. 1. 쿠폰은 임의로 비활성화하지(or 다른 상태도 불변) 않는다. 2. 쿠폰이 비활성화 되는 경우, 소유 쿠폰에서 제거 된다. 이런 경우,, 기획에 따라 다르다라고 이해해야할까요? 저 같은 경우, 이미 발급된 소유 쿠폰 자체를 불변처리 하는쪽으로 얘기하는 편이 심플해보이긴 합니다만, 재민님 의견도 궁금합니다.
찜 목록을 조회해야하는 상황에서, Product 의 상태가 전이되는 경우가 있을거 같은데요. 예를들어, 어떤 이유로 soft delete 되거나, 판매자가 숨김 처리를 하거나,, 이런 경우에는 물론,, 회사마다 정책이 다른거 같긴하더라구요. 예를들어, 들어가니 404 페이지가 뜨는 경우도 있고, 안보여주는 경우도 있구요. 이때 고민되는 부분이 찜 목록 (페이지네이션 한다는 가정) 을 조회할 때 아래의 문제들이 발생하는거 같은데, 혹시 어떻게 푸는게 좋을까요? 1. product 의 상태를 이벤트로 받아서, 찜 목록을 처리한다. -> 이 경우 찜이 많이 된 경우 (유명한 아이템이라 100만개의 찜이 있는) 처리가 애매해보이더라구요. 2. join 을 통해 풀어준다. -> 현재는 상품의 찜 목록이라, 사실 같은 팀내에 같은 서비스가 접근 가능해서 join 이 가능할거 같은데, 이게 찜이 아니라, 나의 리뷰보기 같은 경우 다른 팀에 있을 가능성이 있어서 join 을 통해 풀기 어려운 경우도 있을거 같다는 생각도 드네요.
