엔티티 상태를 조회하는 시점

안녕하세요! 질문 감사드립니다!적어주신 내용과 유사합니다! 단건 조회시에는 코드 기반으로 조회하는게 가능하다고 생각합니다(추가로 ID기반 조회라면 사실 status를 쿼리에 직접 넣어도 조회 데이터 범위가 명확하기 때문에 성능에도 영향이 없습니다)대부분 목록 조회 시에는 직접 쿼리에 질의하는게 맞다고 생각합니다 (페이징 처리가 있다면 더더욱 그래야겠죠)다만 상태 때문에 불 필요한 인덱스가 추가되어야하는지, 현재 인덱스의 효율이 괜찮은지 등의 구성을 보고 판단하는게 중요하다고 생각합니다!추가로 softDelete의 경우 개인적으로는 직관적이고 예측가능하고 누구나 이해하기 쉬우면서 코드 기반으로 테스트하기 더 쉬운 구조를 선호하다보니, 어노테이션 기반을 그렇게 선호하진 않아서 저는 불호에 가깝습니다! 😅그치만 적절히 검토해서 사용해도 무방하다고 생각합니다!모쪼록 답이 되었길 바랍니다! 감사합니다!완강까지 화이팅 해주시고, 완강 후 후기도 기대하겠습니다!

섹션3. 상품 상세. 코드느끼기 12:47 질문.

안녕하세요 질문 감사드립니다!우선 질문의 내용이 조금 헷갈립니다 ProductFinder -> ProductUsecase or ProductUsecase정의한 곳에 Product 서비스 와 ProductSection 서비스를 갖고 안에서 작업을 해보는건 어떻게 생각하실까요?이게 어떤 구조를 말씀하시는 것 인지 모호하네요!ProductProductSecion 명명이 어떤 배경에서 나오는지도 추가 설명해주시면 좋을 것 같습니다! 🤔그리고 뒤에 적어주신 UseCase를 만들어서 ProductUseCase 로 정의하고 ProductService, ProductSectionService 를 주입받아 사용하게 하는 구조를 말하신 것이면, 이것 자체를 규칙으로 정의한다면 나쁘지 않아 보입니다, (다만 개인적으로 UseCase 라는 명명을 좋아하진 않는 것 같습니다!, Product 와 ProductSection 두개 가져오는게 같은 개념안에서 UseCase라고 정의하기엔 다소 아쉽다고 생각합니다)Delegator를 만들어서 구현하는 방법은 지금 상황에서 굳이라는 생각이 들긴합니다!그 정도의 코드 규모가 아니라는 생각입니다!질문이 다소 정보가 적고 추상적이라 적절히 답을 했는지 저도 모르겠네요! 관련하여 상세한 내용이나 예시 코드를 적어주셔도 좋을 것 같습니다!관련해서 추가적인 질문이나 설명은 답글 주시길 바랍니다! 감사합니다!

xxx서비스와 xxx핸들러 의 구분 기준

안녕하세요 질문 감사드립니다!먼저 해당 강의는 여러가지 구현 패턴을 보여주면서 수강생 분들이 최대한 생각을 많이 하시도록 구성하였습니다!그렇기 때문에 구현 패턴이 다양하여서(어떤 코드는 Service 에 Repository 접근과 로직이 다 있음) 그 다양성 자체를 느껴주시면 좋을 것 같습니다!그럼에도 질문의 기준 관련해서 힌트와 생각할 거리를 드리면 Service 와 도구(컴포넌트)들을 나눠놓은 구현 패턴에 대해서는 과거 제 글 중 하나인 지속 성장 가능한 소프트웨어를 만들어가는 방법을 기반으로 작성되었습니다 (인프런에 동명의 무료 강의도 있습니다)해당 글 참고하시면 어느정도 이해가 되실 것 같습니다!간단히 설명드리면 *Service 는 비즈니스 로직을 잘 나타내는 것을 목적을 하고 있습니다그외 도구 컴포넌트들은 구현을 중심으로 구성 되어있으며 재사용성이 높은 도구 역할을 한다고 생각해주시면 될 것 같습니다!그래서 특정 개념에서의 로직이 응집 되어있는 객체 라고 보시는 것은 잘 보신 것 같습니다 😃고민해보시고 추가적인 고민이 있으시다면 편하게 질문해주세요!모쪼록 답이 되었길 바랍니다! 감사합니다!

상품 전체보기가 없습니다. 카테고리는 필수로 선택해야 합니다.

안녕하세요 질문 감사드립니다핵심은 어디를 중심으로 잡을 것인가? 어떤 것에 비중을 더 줄것인가? 우리 비즈니스에선 어떤 선택이 맞을까? 에 대한 결정이라고 생각하기 때문에 CategoryProduct 라고 표현하는 것도 선택가능한 전략 중 충분히 괜찮고 가능하다고 생각합니다!대신 Category 가 그만큼 현재 서비스의 형태와 비즈니스 로직 구조에서 중요한 역할을 하고 있다면 더더욱 타당한 전략이라고 생각 될 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

@Transactional에 관해서 질문드립니다.

안녕하세요! 질문 감사드립니다 😃이 부분은 의도적으로 Transaction 을 걸지 않은 게 맞습니다! (고민해보시라고 의도한 바인데 고민을 하고 계시다니 아주 좋네요!)트랜잭션을 잠시 떠나서 다른 관점으로 생각해보면 "Review 작성 후 Point 작성이 실패했다해서, 반드시 Review가 롤백이 되어야하나?, 이게 고객이 심각한 문제를 겪는 것일까?" 를 생각해볼 수 있을 것 같습니다물론 이것 또한 상황마다 다르기 때문에 반드시! 포인트는 완벽히 그 순간에 100% 지급되야해! 라는 비즈니스적 요구사항과 니즈가 있다면 묶어주는게 맞다고 생각합니다결국 리뷰 작성 시 포인트가 지급이 안되는 문제가 얼마나 빈번하게 발생 하는지, 그것이 얼마나 중요한 사항인지에 따라 선택하면 되는 부분이라고 봐주시고다양한 관점으로 생각해보시면서 고민해보시면서 느껴보시면 좋을 것 같습니다! 😃 다만 지금 구조에서는 문제가 생긴다면 포인트 적립에 대한 재적립을 수동으로 해줘야합니다, 이건 운영 리소스를 쓰겠다는 것 이기 때문에 이 관점으로 우리는 운영 리소스가 적기 때문에 트랜잭션을 걸어야한다! 라는 주장도 아주 합리적이라고 생각합니다 (지급 실패 재시도를 만들면 되지 않나? 라는 의견이 나올 수도 있겠죠!)이런 관점들을 계속 느끼시면서 Point개념이 얼마나 타 개념에 응집되고 결합될것인가?에 대한 고민도 같이 해봐주시면 강의를 100% 즐기실 수 있다고 봅니다! 😀+추가적으로 조금 기능을 발전 시켜간다면 Point 적립 자체는 @Async로 처리하도록 만들 수 있을 것 같습니다 😃 이 관점도 생각해보시면 좋을 것 같습니다!모쪼록 답이 되었길 바랍니다! 추가 질문은 편하게 부탁드립니다!완강까지 잘 부탁드리고 수강평도 기대하겠습니다!

'개념과 격벽' 을 실제 업무에 어떻게 사용하면 좋을까요?

안녕하세요! 질문 감사드립니다!이번 강의는 커머스 도메인를 토대로 개념과 격벽에 대해서 충분히 느껴볼 수 있도록 제작 되었습니다ㅎㅎ (개념 느끼기 부분이 특히 그 부분을 강조해두었구요!)그래서 강의를 완강하시면 개념과 격벽을 어떻게 실무에서 활용 할 수 있을지 느껴 보실 수 있을 것 이라고 생각합니다!적어주신 것들에 대해서 제가 개념과 격벽을 활용하는 전략을 기준으로 의견드리면(제가 개념과 격벽을 언급했으니,,! 제 전략이 답에 가깝겠지만 또 무조건 답은 아니라는 점 참고해주세요ㅎㅎ 사용하기 나름이라고 봅니다)일단 적어주신 순서 대로 활용하는 것은 아닙니다!적어주신것의 순서를해 볼 수있을까~ 싶은데 애매하네요 대략 제가 재구성 해보겠습니다(사실 모든 상황에서 한가지 전략으로 활용할 순 없습니다, 회사의 상황, 규모, 기획팀 역량, 존재유무 등등 너무 고려할게 많습니다, 일반적이라고 가정하고 보편화 시켜서 적어보겠습니다)현재 전달 받은 요구사항을 분석하고 이해한 뒤 구현을 먼저 진행한다잘 못 된 요구사항, 변경 되는 요구사항, 만들다 보니 모호한 부분이 분명히 있을텐데 일정 내에서 이것도 수용하며 구현을 진행한다구현하면서 어떤 것들이 우리의 S/W의 비즈니스와 코드에서 핵심이고 중심인지 이해한다 (신규 코드라는 가정입니다, 레거시라면 레거시 현황을 이해하는것이 선행)핵심과 중심인 부분을 최대한 의존을 끊어내고 순수 할 수 있게 구현을 계속 진행한다분명히 초기에 구현 하면서 생각한 것들이 바뀔 수 있음구현이 완료되어 요구사항이 충족되어 기본적인 테스트를 성공 시킨다현재 구현 된 요구사항과 비즈니스와 코드 기준으로 개념과 격벽을 개념도에 그린다팀 내(개발,기획,+디자인) 등 공유하여 인식을 맞춘다 우선 저는 이런식으로 활용을합니다! 대부분의 신규 서비스 만들때 기준으론 초기 mvp가 나오고 나서 개념도를 최종 버전으로 그렸던 것 같아요!먼저 구현 중간중간에 개념과 격벽을 정의하면서 진행해도 되는데 일반적으로 요구사항이나 기획이 변경 될 가능성이 있으니 추후에 그리는게 좋다고 생각하긴합니다!사실 이런 순서보다 핵심은개념을 나열하고격벽을먼저 만들면 안 된다는 것 입니다그러면 결국 구현 먼저가 아니라 설계 먼저 하고 있는 것 이기 때문이라고 생각합니다 😃 (발표 후기에도 말했지만 설계 먼저 하는게 무조건 틀리다는 의견은 아닙니다ㅎㅎ)저는 여전히 구현 먼저 하는게 중요하다고 생각하는 쪽입니다.물론 코드를 구현을 하면서 생각을 계속 해야겠죠! (이 클래스를 어디서 끊을지, 누구누구를 알게 될지, 이 클래스가 개념적으로 가치가 있는지? 있다면 얼마나 중요한 개념인지,,, 등등)구현이 어느 정도 진행되고, 충분히 이해도가 생겼을때 개념을 정의하는게 좋다고 생각합니다!모쪼록 수강 감사드리고 답이 되었길 바랍니다! 강의 완강 후에도 느낌이 잘 안 느껴지시면 다시 질문주시면 좋겠습니다! 감사합니다!

타임베이스 정산 배치 실패 시 처리에 대해

안녕하세요! 질문 감사드립니다!우선 가장 리소스 효율적으로 접근한다는 측면에서는 배치 시간 간격을 더 멀리 띄워 놓으면 당장 며칠은 버틸 수 있을 것 같습니다!(반대로 각 배치의 성능을 올려서 시간을 단축 할 수도 있겠죠ㅎㅎ 이 부분도 어떻게하면 시간 단축이 가능할지 고민해보시길 권장드립니다!)이어서는 2번의 전략을 활용 할 수 있을 것 같습니다 (1번은 적어주신대로 지금 우리가 하기엔 리소스 효율이 없다고 가정하겠습니다)여기서 생각해보실 부분은 이전 배치의 실패 이력을 체크하는 것으로 해결이 가능한지 고민해보시면 좋을 것 같습니다!1시 배치가 4시30분에 정상적으로 끝났다면, 4시 배치가 수행 되려 할때 실패 이력은 없을 것 이기 때문입니다!그럼 추가적인 데이터를 관리한다면 말씀하신 구현의 느낌으로 해당 문제 해결이 가능 할 것으로 보여집니다!추가적으로 고민이 되시는건 편하게 댓글이나 추가 질문 부탁드립니다!모쪼록 답이 되었길 바라며 강의가 도움이 되었길 바랍니다! 완강까지 고생하셨습니다!

강의 PDF는 어디에서 다운로드 할 수 있을까요?

PDF는 압축 해제해보시면 제미니의 개발실무 - 커머스 백엔드 - v1.0.pdf 라는 파일로 동봉되어있습니다!

취소-코드느끼기 / Cancel을 별도의 스키마로 관리하는 방식의 장점

안녕하세요! 질문 감사드립니다!해당 상황은 "취소 목록 조회"를 만드는 상황을 가정하고 설명하였습니다! (영상 보니 이 상황 설명이 디테일하지 않았네요!)만약 "결제가 취소의 상태를 관리"한다면 createdAt은 취소 시점을 나타낼 수 없기 때문에 updatedAt으로 기간을 지정하고 정렬해야합니다이 구조에서 결제 데이터가 더 많아진다고 가정하면 조회 시 updatedAt 기준으로 전체 Payment 를 조회하면서 "취소 상태"인 것을 조회해야하는 비효율이 발생하는 구조가 됩니다(where state = 'CANCELD' and updatedAt > ?)이렇게 되면 데이터 규모가 결제가 많고, 취소가 적다면 데이터 조회에 비효율이 발생하게 됩니다(updatedAt 기간을 지정해도 대부분 데이터는 state = 'PAID' 일것이기 때문에, 데이터 모수 자체가 많음)물론 고객이 느끼는 서비스 측면에서는 userId가 조건에 들어갈 것 이기 때문에 대부분 유저 기준으론 크게 문제가 없습니다만어드민 기능으로 취소 목록을 조회해야한다고 하면 위에 말한 비효율이 더 크게 느껴집니다물론 이 부분도 초반엔 인덱스 구성으로 어느정도 해결이 가능합니다만 개인적으로 추가적인 조회 패턴 때문에 인덱스가 이미 넉넉한데 updatedAt + state 에 대한 인덱스를 더 넣어야하는 부분은 아쉽다고 생각합니다.* 추가적인 유리함은 강의에서 설명드린 데이터 시스템, 정산 구현 등등으로 이해해주시면 될 것 같습니다!'규모적으로 선택하라. 테이블이 적고 테이블 로우가 적고 접근 범위 자체를 줄일 수 있고, 이런 장점으로 보면 페이먼트 테이블을 만들어도 되는데요'이 부분은 규모에 따라 Payment 테이블에서 Cancel State 를 관리해도 된다는 의미로 설명드렸습니다!가령 결제건이 적거나 (정기결제 기반 등), 취소가 완전히 거의 없거나, 취소와 결제가 비등한 수준이라거나, 결제 후 3일 뒤엔 취소가 불가능하다거나 (특정 산업) 이런 규모에 따라 선택이 가능하다는 것을 의미하였습니다!핵심을 설명하느라 빠르게빠르게 넘어간 부분이라 많이 모호 할 수 있는 부분인데 잘 짚어주셨네요! 질문 감사드립니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

Order->Payment->Cancel 형태에서 경계의 모호함이란?

안녕하세요 질문 감사드립니다!Order -> Payment 추후 배송이 생길 경우 자연스레 Order의 상태가 중심이 되지 않고 Payment의 "결제완료" 상태가 중심이 될 수 있습니다, 물론 이것이 틀린 것은 아니나 강의에서 말했든 "결제는 주문을 완료 시키기 위한 행위"로 서비스의 기준을 정하려고 하기 때문에 명확하게 경계를 긋는게 좋다고 봅니다!또한 추가적으로 주문에 대하여 다른 기능으로 확장 될 시 Payment 가 중심이라면 상태에 대한 책임과 조회 시 Payment 를 계속 체크해야하는 등의 형태로 Order 와 Payment가 짝꿍처럼 다녀야하는 문제가 있을 수 있어보입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!