------------------------------ 해결 방안-------------------------------저와 비슷한 이슈가 있으신분은 이렇게 처리 부탁드립니다! 인텔리제이 설정에서 Preferences > Build, Execution, Deployment > Build Tools > Gradle에서Build and run using : GradleRun tests using : Gradle 이렇게 수정 하고 다시 시도 부탁드립니다!!!  쿠케님 감사합니다 :)    안녕하세요 우선 좋은 강의 만들어주셔서 정말 감사드립니다.GET - http://localhost:8080/cache-strategy/NONE/items/{{itemId}} 해당 API 를 호출 하게 되면ItemController -> KukeCacheAspect -> KukeCacheKeyGenerator -> ItemNoneCacheService  대충 이런 흐름으로 가게 되는데요.KukeCacheKeyGenerator 객체에서 for (int i = 0; i<args.length; i++) { context.setVariable(parameterNames[i], args[i]); } parameterNames 객체에 NPE 에러가 발생 되고 있습니다.코드는 강의 자료실 통해 제공해주신 코드로 실행 해보았습니다. 이 부분 어떻게 수정을 해야 할까요?  

JobListener 를 구현하면서 동적으로 executionContext 를 밀어 넣을때 설명이 내가 이해한게 맞다면 오타가 발생한 듯 하다. 이렇게 InfiltrationPlanListener를 JobBuilder의 listener() 메서드로 등록해주면 beforeStep() 메서드에서 동적으로 생성한 데이터를 각 Step에서 참조할 준비가 완료된다.해당 문구의 작업은 JobExecutionListener 로 동작한 부분으로 beforeStep 이 아닌 beforeJob 에 의해서 동적으로 생성되는게 맞지 아니한가?!

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

킬구형 ㅎㅇ 요즘 형 spring-batch 오픈소스 이슈에서 잘 보고 있어. 진짜 형 대단한 거 같아.형 그런데 나는 궁금한 게 있어 일단 이번에 나도 간단한 오타 수정으로 기여를 하기는 했는데 나도 이슈를 한번찾아보고 싶은데 감이 안 잡혀서 형은 보통 이슈를 어떻게 찾는지, 아니면 오픈소스를 볼 때 팁 같은 게 있는지 궁금해.

킬구형 RetryPolicy 작동 방식이 policyMap에서 우선 발생한 에러의 상위 카테고리를 찾고, RetryPolicy에 들어있는 SimpleRetryPolicy가 실제로 각 에러에 대해 어떻게 처리할지를 정하는 것 같은데 그러면 두 에러가 상속 관계에 있어야지만 정상적으로 작동하는 거 같은데 맞아?그런데 예제 코드에 있는 HttpTimeoutException와 HttpServerErrorException는 상속 관계가 아니어서 아마 의도대로 작동하지 않을 것 같은데 한 번 검토해봐줄 수 있어?참고로 나는 java17 + spring-boot-starter-batch:3.5.6 환경으로 진행중이야

킬구형 강의 특별해서 좋아~ 즐길 수 있을거 같아! 이런 강의 의도를 더 믿음있게 하기 위해서 오타 제보~ 섹션 1. SYSTEM INIT: 스프링 배치 종결의 서막 2. 배치 처리, 시스템 종결의 서막💀 Flexible.png 이미지 내 오타 ItemReader interface 를 상속하는 RedisItemWriter 는 없다. RedisItemReader 가 존재한다 

안녕하세요 제미니님, 유튜브부터 잘 보고 있는 수강생입니다. 항상 좋은 영상과 강의 감사합니다. 다름이 아니고 블로그에 작성해주신 글 [지속 성장 가능한 소프트웨어를 만들어가는 방법] 중 소프트웨어 레이어에 대해 언급을 해주셨는데, 해당 강의의 프로젝트가 이와 유사한 구조인 듯합니다. 질문:제미니님은 현업에 계실 때에 비즈니스 레이어(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 레이어에 위치해도 되는 것일까?적다보니 굉장히 길어진 느낌이네요... 강사님은 어떤 생각이신지 궁금합니다!긴 글 읽어주셔셔 감사드립니다!

안녕하세요, 강사님. Product의 상세 정보(Full Information)를 ProductSection으로 분리한 이유가 궁금합니다. 섹션3.상품상세 - 코드 느끼기 수업 중 07:50 지점에서'상품 상세 정보(Full Information 부분)를 이미지만이 아닌, HTML과 이미지의 복합으로도 구성할 수 있다고 전제하고 ProductSection을 만들었다.'고 하셨는데 '상품 상세 정보를 이미지+HTML로 구성'하는 것이 ProductSection으로 분리'한다는 결정에 어떤 영향을 준건지 모르겠습니다. 제가 생각해 본 경우는 다음과 같습니다.상품의 Full Information이 여러 이미지와 HTML 요소로 구성되니 하나의 상품에 여러 요소가 연관되는 일대다 관계를 만들기 위해 별도의 개념으로 분리시켰다.Full Information을 이미지 또는 HTML로 구성할 때 이미지인지, HTML인지 타입 정보(ProductSectionType)가 필요하니 높은 응집성을 위해 별도의 개념으로 분리시켰다. 상품 정보에 특정 속성에 대한 정보(이미지인가, HTML인가)가 속성으로 포함되는 것보다는 아예 분리하는 것이 응집성이 높지 않을까 싶습니다.위의 부분 외에 분리의 이유를 예상해보면 다음고 같은 듯 합니다.ProductSection이 상품의 본질은 아니고 '상품을 어떻게 보여줄 것인가, 어떻게 판매할까'에 관한 것상품의 생성과 함께 반드시 따라 붙어야하는 종류는 아님조회 패턴, 수정 패턴이 다름상품 정보보다는 상품 섹션이 더 자주 바뀔 것 같습니다.수업 잘 듣고있습니다.감사합니다. 

안녕하세요 강의 잘 보고 있습니다! 현재 아키텍처는Controller -> Service -> Resposiotry 구조로 흐름이 이어지고 Service는 각 개념에 대한(Product, Review 등..) 조회 쿼리를 묶는 Finder, 그외 CUD 기능을 묶는 Mananger 또는 Handler ? 로 이뤄져 있습니다.이 구조는 예전에 토스 슬래시 "지속 성장 가능한 코드를 만들어가능 방법"에 대해 인상 깊게 봤는데 조회용, CUD용을 별도 컴포넌트로 관리하고 Service는 이를 핸들링 하는 파사드 패턴의 구조와 유사하게 생각했었습니다. 여기서 질문이 있는데요Product와 Review는 격벽을 두는 서로 다는 개념이지만 Product라는 1급 개념이외의 하위 개념 (섹션, 카테고리)들은 상품을 추가할 때 하나의 트랜잭션으로 묶이는 대상이라고 생각이 들었습니다. 그럼 이 경우에는 리뷰는 상품과 서로 다른 개념이기 때문에 서로를 알지 못하지만, Product의 하위 급수 개념들은 ProductService 내에서 하나의 트랜잭션으로 묶는,즉, xxxService는 동일한 개념에 속한 개념들을 하나의 트랜잭션으로 묶는 파사드의 일종이라고 생각하면 될까요? 만약 맞다면 개념과 격벽을 이해하기에 각 개념은 하나의 트랜잭션으로 묶여야하나?에 대한 고민도 개념을 구분하는 방법이 될 수 있겠구나!라는 생각이 들기도 하네요 항상 잘 보고 있습니다 감사합니다!

안녕 킬구형 나는 오랜만에 배치 복습하려고 형 강의 구매했어!일단 그냥 책 보면서 실무에서 배치를 운영을 하려니깐 고민이 있어.형 생각이 궁금해서 질문을 남겨 1. Jenkins , Spring Batch형 일단 나는 Batch를 실무에서 Jenkins 스케줄러 + Batch 이렇게 사용하고 있어. 그런데 배치 인프라에 대해서 요즘 고민이 생기는 거 같아. 나는 job enabled를 false로 설정하면서 운영하고 있는데 만약에 배치가 N개로 운영되고 있다고 가정하면 port 충돌에 대해서 고민이야 물론 parameter로 port를 넘겨줄 수 있어서 현재는 스크립트로 남는 포트를 parameter로 넘겨주면서 사용하고 있어. 간편성을 생각한다면 그냥 enabled를 true로 하고 api 형식으로 그냥 호출만 해주면 이런 복잡한 과정 없이 사용할 수 있을 거 같은데 어떻게 생각해. 2. CI/CD하나의 jar에서 여러 개의 배치가 돌아가는데 이때 CI/CD 과정에서 문제가 생길 수 있을 거 같다. 현재는 ln 심볼릭 링크로 해결을 하고 있는데 이게 적절한 방식인지? 아니면 다른 방식이 있는지 궁금해 3. JobParametersIncrementer형 Spring Batch에서 JobParametersIncrementer(RunIdIncrementer 등) 관련해서 궁금한 점이 있어 만약 업무적으로 특별한 파라미터(날짜, 키 등)가 없는 반복 배치라면이 때는 run.id와 같은 증분기 기반의 값으로 JobInstance의 고유성을 관리 하지만 업무적으로 중요한 파라미터(날짜, 키 값 등)가 있다면 이 경우에는 run.id 대신 해당 파라미터를 JobInstance의 기준으로 써야 멱등성 및 실패/재실행 제어가 더 적합하다고 생각해. 실제로 파라미터가 없는 경우에는 run.id로 멱등성을 보장하고, 파라미터가 있는 경우에는 run.id 증분기를 쓰면 오히려 동일 파라미터로 재실행/복구 등 업무상 중요 컨트롤이 어렵지 않나요? 이런 경우 run.id 증분기를 같이 쓰는 게 맞는지, 아니면 아예 쓰지 않는 게 맞는지 설계 원칙이 궁금해요.https://github.com/spring-projects/spring-batch/issues/4910https://github.com/spring-projects/spring-batch/wiki/Spring-Batch-6.0-Migration-Guide

안녕하세요, 강사님.강의 잘 듣고 있습니다. '섹션2. 상품 목록 - 코드 느끼기' 수업에서룰셋에 의한 암묵적인 구현으로 '카테고리-상품 맵핑이 존재하는 상품은 ACTIVE 상태'임을 보장할 때, 다음 두 가지 방식을 말씀하셨습니다.연관된 맵핑이 존재한다면 상품을 삭제할 수 없다.상품을 삭제할 때 연관된 맵핑이 함께 삭제된다.어떤 방법을 선택할지는 운영진들과 소통해야한다고 하셨는데 (16:30~)처음에는 운영진과 왜 소통이 필요한건지 잘 이해가 안되어서 고민해보니맵핑이 단순히 다대다 연관관계 표현을 넘어 도메인 개념으로 동작하여 운영진에게 노출되는 경우를 말씀하신건가 싶습니다. 만약 그렇지 않다면 설명 부탁드립니다. 예시 맵핑에 추가적인 정보가 붙는다고 가정해보면 연관관계 표현뿐 아니라 하나의 엔티티, 도메인 개념으로 기능하고 운영진들에게도 노출된다.ex) 프로모션 이벤트에 포함된 상품마다 할인율이 다르다면 promotion-product 맵핑에 할인율이 포함되고, 운영진들도 프로모션-상품 조합마다 할인율을 조정해야함. ->promotion-product 맵핑 자체가 업무 개념이 되어 운영진에게 노출되고 사용되어짐.룰셋에 의한 암묵적 구현은 다음 방식들 중 선택할 수 있다.모든 프로모션에서 A 상품을 제외해야 A 상품을 삭제할 수 있다. (하나라도 맵핑이 있다면 상품 삭제 불가)A 상품을 삭제하면 모든 프로모션에서 제외된다. (상품 삭제 시 연관된 모든 맵핑 제거)따라서 어떤 룰셋을 정의할지 운영진들과의 소통이 필요하다. 

안녕하세요 유투브를 쭉 챙겨보다 강의를 내셔서 바로 달려온 구독자 중 한명입니다 !다름이 아니라 섹션 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 어노테이션이 붙지 않은 걸 보니 테이블로 관리하지 않는 것 같은데 여기에 두신 이유가 궁금합니다! 감사합니다.

안녕하세요. 정말 재밌게 수강중입니다. 다름이 아니라 데이터 검증 책임에 대해서 궁금한게 있습니다.저는 사용자에 의해 넘겨받은 데이터를 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) } } 

킬구형 1장 - 작전3에서 아래와 같이 얘기한 부분에 대해 궁금한게 있어. '리스너는 감시와 통제만 담당한다. 실제 시스템 제거 로직(비즈니스 로직)은 분리하라. 리스너가 너무 많은 일을 하면 유지보수가 어려워지고 시스템 동작을 파악하기 힘들어진다' 청크 기반 배치 잡이라고 하고 A라는 테이블에서 데이터를 읽어와서 B라는 테이블에 데이터를 삽입하는데 B 테이블에 데이터가 없다면 삽입, 있다면 수정하는 로직이 있어. 이 과정들이 모두 끝나고 마지막으로 B 테이블에 수정 날짜 컬럼이 잡 시작 시간보다 이르다면 A 테이블에 데이터가 없으므로 B 테이블에서 이러한 데이터들을 삭제하려는 로직을 넣는다고 했을 때 아래 궁금증들이 있어.1. 위 얘기를 토대로 생각해보면 삭제 로직은 청크 기반 스텝 이후 태스크릿과 같은 다음 스텝으로 넣는게 좋은 것 같은데, 실무에서는 해당 잡 전용 리스너를 하나 추가로 만들어서 afterJob 메서드에 배치 상태가 COMPLETED인 경우에 삭제 로직을 실행하도록 하는 방식은 지양하는 편인거야? 전용 리스너를 만들어서 사용하는 경우도 있어?만약 리스너에 삭제 로직을 넣는다고 했을 때 리스너에서 데이터 삭제 과정 중 오류가 발생한 경우에는 잡이 실패 상태로 종료되는거지?2번과 같은 맥락인데 리스너에 삭제 로직을 넣는 경우 트랜잭션이 필요할텐데 리스너는 트랜잭션 범위가 어떻게 돼? 스텝에서는 청크 범위, 태스크릿의 반복 범위라고 본 걸로 기억하는데 리스너는 트랜잭션 설정 자체가 안되는건지 리스너 범위 내부에서만 설정되는건지 궁금해.