취소-코드느끼기 / 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가 짝꿍처럼 다녀야하는 문제가 있을 수 있어보입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

PointBalanceEntity에서 낙관적 락

안녕하세요! 와르락님 질문 감사드립니다!제가 답변을 드리기 전에 와르락님은 어떻게 생각하는지 궁금합니다포인트에 대한 문제를 낙관적 락하고 비관적 락으로 각각 해결했을때 발생 할 수 있는 문제와 현상 또는 각각의 이득이 무엇이라고 생각하시나요? 😃생각해보시고 댓글 주시면 제 의견도 드려보겠습니다!

테스트 코드

안녕하세요 승환님! 질문 감사드립니다!강의를 보고 충분히 고민하고 생각해보고 계신 것 같아서 아주 보람차네요 😃테스트 코드의 경우는 베스트를 기준으로 말하면 각 모듈별 테스트 완결성을 갖도록 테스트를 구성하면 좋다고 생각합니다. (모듈별로 테스트가 완료 된 상태라서 모듈 자체에는 우려가 적은 상태를 만드는 수준의 테스트) 제 경우에는 가능하면 많이, 필요한 부분에 테스트를 작성하는 전략을 씁니다Service, Handler 구분 없이 필요하다면 단위 테스트를 작성하고, Service 의 경우는 필요 시 통합테스트를 통해서 추가 검증을 하기도 합니다 (연결 고리 부분 및 데이터에 대한 검증)테스트는 여러 목적과 효과가 있지만 결국 우리가 만든 소프트웨어 배포를 누를때걱정이 되지 않아야한다고 생각합니다 😀(추가로 당연한 것이지만 JPA Repository 나 이런 정적으로 검증이 되는 영역은 굳이 별개 테스트를 작성하지 않습니다! 이런 프레임워크나 라이브러리는 필요하다면 기능적 테스트를 작성해두는 편입니다. ex] JPA 변경감지가 잘 동작하는가? 모쪼록 답이 되었길 바랍니다! 감사합니다!

리뷰의 개념도에서 `Product`를 표현하지 않은 이유에 대해서

안녕하세요! 질문 감사합니다! 고민을 많이하시면서 강의를 아주 잘 활용하고 계시군요! 멋집니다! 👍제 생각 기준으로 말씀드려보면!리뷰의 대상이 OrderItem이라고 표현 하는 것은 개념적으로 맞지 않다고 생각합니다(물론 Review 가 Order 개념을 이미 알고 있는 형태의 개념도는 맞지만 이는 ReviewPolicyValidator에서 orderItem 을 활용하고 있기 때문에 나온 부분입니다)핵심적으로 정리하면 리뷰가 OrderItem에 작성 될 수 있는 것은 정책적인 부분이라고 생각합니다추후에 리뷰 작성 정책이 변경 되거나 배송이나 다른 기준이 생긴다던가 등등 정책적인 변경에 영향이 간다고 보여집니다, 고로 개념적으로 연관 되어 있다고 보기는 어려울 것 같습니다또한 엄밀히 말하면 논리적으론 Review는 Product 를 약하게는 알고 있습니다 ReviewTargetType 자체가 Product 를 지칭해버리고 있죠reviewKey 필드에 orderItem 의 id 가 조합해서 들어가지만 이건 단순 문자열의 조합일 뿐이라고 봅니다 (prefix 문자열 또한 OI_*, POLICY_* 등등으로 쓸수도있지만 가독성을위해 풀어둔 상태구요!)그래서 저는 Review의 대상은 Type 과 Id 가 존재한다면 누구나 될 수 있다 가 맞다고 봅니다주문한 정보은 현재 정책 기준 리뷰 작성의 필수 조건 일뿐 리뷰의 대상이라고 생각하지는 않습니다기획팀 등 누군가와 대화를 가정하여 "상품에 리뷰를 쓸텐데 왜 리뷰 개념이 상품 개념과 연결되지 않나요?"라는 질문을 받았을 때 "리뷰 대상을 범용적으로 지정하도록 설계해 상품 개념을 직접 의존하지 않기 때문"이라 대답하면 코드/스키마 관점의 대답이라 생각됩니다.이 부분은 아주 좋은 접근입니다! (회사에서 이런 질문을 받을 수 있으면 좋겠네요ㅎㅎ)이 관점에서 개념도를 다루는 전략의 확정이 필요합니다위에 언급했던 것 처럼 Review는 엄밀하게는 Product 를 알고 있습니다.다만 여기서 우리가 장기적으로 리뷰 시스템을 범용성 있게 만들어서 추후 셀러 리뷰, 배송 리뷰, 브랜드 리뷰 생길 수 있다, 장기적으로 더 나아가 리뷰 시스템을 별도의 플랫폼화 할 가능성이 있다 (이것은 코드/스키마적 관점은 아님) 라는 합의가 있었다면 자연스러운 개념도가 된다고 봅니다.(다만 여기서 "지금 우리 상황에서 굳이 그렇게까지요??? 그거 언제할건데요?;; 우리 개발자 셋인데요?" 라고 생각해봐야한다고 봅니다ㅎㅎㅎ 그런 생각이 나시도록 의도하긴 했습니다ㅎㅎㅎ)그러므로 전사적은 아니더라도 관련자들은 충분히 인지해야하는 부분이라고 봅니다(그리고 오히려 저렇게 훌륭하게 물어봐 주면, 자연스럽게 우리 서비스의 성장 방향성을 다운로드 해줄 수 있기 때문에 이 기준대로 작성하는게 좋다고 봅니다) 만약 그런 합의가 없거나 관심이 없어서 적어주신대로의 혼란이 있을 수 있다면 더 작은 점선 or 연한 점선(그 만큼 연관성이 얕다는 것을 표현) 하는 식으로 표현할 수 있을 것 같습니다다만 문제는 그렇게 되면 개념도가 너무 복잡해집니다, Review 작성 대상이 많아지면 많아질 수록 화살표들의 복잡하게 연결되고 복잡해 보일 것 같습니다, 그래서 필요하다면 별개로 느슨한 연관 개념도 or 리뷰 상세 개념도 같은 것을 그리는게 낫지 않나 싶긴합니다(물론 현재 우리 상황에선 그렇지 않긴합니다ㅎㅎ)참고로 제가 말한 것 또한 현재 강의 예제 상황에 맞춘 제 기준에 의한 생각입니다 😃생각하시는데 참고가 되었길 바랍니다!아무튼 강의를 아주 잘 느끼시고 고민하시는 것 같아서 너무 뿌듯합니다! 완강까지 화이팅이고 완강 수강평 기대하고 있겠습니다!!모쪼록 답이 되었길 바랍니다! 감사합니다!

따닥방지

앗..? 질문자분 정보가 삭제되신 것 인가하여서 우선 간단히 답변 적어둡니다!사실 구현을 멱등적으로 한다면 API를 나누는 것으로도 따닥 방지를 할 수 있습니다!결국 따닥 이슈는 클라이언트 단과 구현 전략을 협의하는게 중요한 부분 중 하나입니다또 별개로 지금 구현 자체는 추가와 삭제가 이미 나뉘어져있기 때문에 매우 쉽게 API를 분리할 수 있는 구조이기도합니다모쪼록 제가 의도했던 질문 중 하나인데 혹시나 나중에라도 참고가 되시길 바라겠습니다!

레이어간 흐름에 대한 엄격함

안녕하세요 질문 감사드립니다!우선 가장 중요한걸 말씀해주셨는데요!팀 단위의 개발에선 컨벤션이 어느정도 정해져있는게 개발 생산성에 유리하지 않을까이건 무조건 맞다고 생각합니다 😃다만 저는 어느 정도로 강제하였냐.......에서는 꽤나 복잡하고 고정 되어 있지 않습니다, 관련해서 유사한 질문이 있었어서 그 답변을 차용하여 답변드립니다!사실 제 우선순위라 하면 가장 중요한 것이 회사/팀의 역량 수준이 들어가버립니다그렇기 때문에 같이 일하는 동료들의 역량이 조금 아쉽다면, 약간의 경직 된 룰을 만들어서 팀을 유도합니다물론 이 수준을 영원히 유지하지 않습니다 신입 팀원들이 어느정도 도메인에 익숙해지고, 구현에 익숙해진다면 좀 더 유연한 룰로 변경해나가는 것을 진행하는편입니다.그래서 단순히 상황을 판단하긴 하지만 같이 일하는 동료를 기준으로 판단하는게 가장 큰 기준이 되는 것 같습니다그렇다면 만약 베스트 팀이라면 제 경우는 소프트웨어가 성장하는 시점에 맞추어서 성장시키는 것을 선호하기 때문에 굳이 과하게 만드는 방향으론 개발을 하지 않습니다(다만 제 커리어상으로도 회사에서 이렇게 할 수 있는 팀을 만난 것은 딱 한번 정도 같습니다 ;ㅁ; 현실적으로 어렵습니다......)그래서 대부분 조금 타이트하게 통제된 정책을 만들고, 회사에서 사람이 바뀌거나 신입이 들어오더라도 적응하기 쉽고 작업하기 쉬우면서 품질을 직관적으로 볼 수 있는 형태를 더 선호합니다!종합적으로 정리하면 회사/팀 수준과 일하는 상황을 느껴보고 판단하여 얼마나 강제할지 결정합니다 😃 (상황에 따라 매우 심하게 강제해본 적도, 엄청 느슨하게 해본 적도 있습니다 그리고 그 강도도 시간과 팀의 성장에 따라 유연하게 변경했던 기억이 있습니다)모쪼록 답이 되었길 바랍니다! 감사합니다!추가로 궁금한 것이 있으시면 질문 주시길 바랍니다! 😃

찜 기능에서 의문점

안녕하세요 질문 감사드립니다!해당 부분은 말씀해주신 내용이 맞습니다ㅎㅎ 이상함을 느끼시는 분들이 있을 거라 생각했는데 이제야 질문이..! 코드 꼼꼼히 보시고 고민하고 계시는 것 같아서 아주 기쁩니다!(만약 클라이언트가 그렇게 API 를 나눠자고 요청했다면 이건 무조건 설득해야하는 영역 같습니다 😃)추가로 찜하기에 상품이 존재하는지 내리는 영역은 찜하기 개념에서 검증이 가능하다고 생각합니다.(개념 정리상 찜은 상품을 알고 있으니까요!)찜은 실존하는 상품에 대해서만 찜이 가능하다는 전제가 맞아보입니다!그래서 찜 정보는 있는데 상품이 없다면논리적 오류로 봐야할 것 같습니다대신! 상품이 삭제된 상태라면 어떻게 노출할 것인지? 찜 목록 응답에서 아예 제외할 것인지? (그러면 페이징은....?)아니면 "삭제 된 상품입니다." 로 고객에게 보여줄 것인지? 에 대한 요구사항의 정의가 필요할 것 같습니다!모쪼록 답이 되었길 바랍니다! 완강까지 화이팅입니다!

주문 - 개념 격벽 의존 방향과 실제 코드의 의존 방향 불일치 질문

안녕하세요 질문 감사드립니다!1.지금 저희 강의 상황 기준 컨트롤러 영역은 외부(우리 의도에 의해 변경이 일어나지 않고, UI에 의존적이거나 특정 요구사항에 의존적이라 통제력이 약한)에 가까운 영역이라 생각합니다그래서 OrderController는 Order 개념을 표현/표출하는 표현 영역 정도로 생각합니다고로 개념 관리 및 개념도 작성시 그 부분은 표현하지 않는편입니다! (다만 당연히 이건 법은 아니고 제가 대부분 경우의 작성하는 전략입니다 :D)1-a.결국 개념 설계와 개념도 작성 시 어디를 기준으로 할 것이냐가 핵심인 것 같습니다제 경우는 각 높은 수준의 응집 된 비즈니스를 조합하는 수준의 Facade라면 개념으로 치지 않을 것 같습니다!다만 각 개념을 넘어서 개념 융합 관점의 관리 지점으로 볼 것 같습니다! (이걸 별도로 다룰 것이냐도 선택이라 생각합니다! 결국은 컨트롤러가 너무 과해질 때 이런 것들이 필요하게 될 것이니까요!)2.현재 기준으로 보면 OrderService 에서는 Cart 를 모르고 있는 구조지만, Cart -> NewOrder 를 만드는 구조입니다만 (사실 해당 로직을 Controller에 넣어버릴 수도, CreateOrderFromCartRequest 에 넣을 수도, NewOrder.from(...) 으로 만들 수도 있죠ㅎㅎ)이 구조에서 생각해 볼 것은 NewOrder는 개념 객체인가? 맞다면 얼마나 급수가 높은가? 또는 데이터 객체일까? 에 대한 것 같습니다또한 A가 B의 하급 객체를 만드는 것을 격벽을 넘었다고 정의 할 것인가? 에 대한 기준과 고민도 필요합니다결국 이것 또한 개념과 격벽 관리 기준을 어느 수준으로 깊게 정의하고 관리 할 것이냐가 핵심같습니다 😃그리고 구현 측면에서 어떤 구현이 자연스러울까를 같이 봐야할 것 같습니다(위에 적은 Controller나 Request 객체에 넣으면 격벽이나 구현을 만족 시킬 순 있지만 그게 올바른 구현인가? 의 문제가 있다고 봅니다)그래서 종합적으론 현재 내용은 제가 의도한 바가 맞습니다 😃 (이 질문이 올라온 것을 보면 충분히 제 의도와 목적이 달성한 것 같네요 +_+)이런 개념 관리 전략이 정답이 아닐 수 있으니 자유롭게 고민 해보시길 바랍니다!질문 주신 내용을 보니 충분히 많은 생각을 하고 계신 것 같습니다! 👍3.해당 개념과 격벽을 유지하면서 구현하는 전략은 다양하게 있을 것 같습니다만적어주신 것과 같이 그렇게 복잡해져야한다면 차라리 격벽을 통과하는 것으로 정의하는게 맞을 것 같습니다 😅여기서 가~~~~~~장 중요한 것이 있는데요!개념과 격벽이 먼저 설계되고, 코드가 구현 되는 형태가 되면 안됩니다!강의 순서도 그렇지만 요구사항을 느끼고, 구현(당연히 이때 개념과 격벽을 고민 하긴하지만 설계를 정의하는 것은 아님)을 한 다음그 구현을 토대로 개념을 정리하고 격벽을 구성하고 그에 대한 개념도를 그리는게 제 기준엔 맞습니다 😃그래서 적어주신 것 처럼 개념과 격벽을 의존방향을 맞추는 구현은 하지 않는게 맞습니다! (엄청 미묘하지만 약간의 차이로 주객전도가 되버립니다!)개념과 격벽이 이렇네! 이 기준으로 구현하자! => X요구사항을 추가 반영했더니 구현이 변경되고 추가적인 개념과 격벽이 변경됬네? = O모쪼록 답이 되었길 바랍니다! 완강까지 화이팅입니다!완강 후 수강평도 기대하겠습니다! 감사합니다!

컬렉션 조회에서의 데이터 조립

안녕하세요 질문 감사드립니다 우선 적어주신 2가지 방법 모두 유효하다고 생각합니다!이 경우들은 결국 같이 조회되는 부가 데이터의 성질과 본질을 생각해서 각가 대응하면 좋을 것 같습니다가령 단순한 세일 정보라고 한다면 Product 자체적으로 데이터를 만들 수 있을 것 같구요 (정가 != 판매가 == 세일 표기)현재까지 팔린 갯수 = Order 개념에 의존해야하므로 2번 전략으로 사용 가능 할 것 같습니다대신 2번 전략을 유지한다했을때 컨트롤러가 너무 많은 책임과 역할과 로직을 수행할 수 있습니다이렇다면 상위 컴포넌트를 구축해서 구현하는게 좋다고 생각합니다! ex) ProductDisplayXXXXXX (WrapperService 건 facade 건 Decorator 건 이름은 정하기 나름이라고 봅니다)저는 가급적 각 개념의 Service 는 본질적인 기능을 제공하는데 초점을 맞추는 편입니다!(상품 id 목록의 주문 수를 가져와줘 => 주문 개념에 속할 수 있는 순수한 기능)이 함수 또한 반환하는 객체가 있을 것인데 그럼 이때 부가 데이터를 담고 반환하는 객체 또한 개념 객체로 생각해야 할까? (화면 구성에 따라 달라지는 데이터인데 내부 개념으로 정의해도 맞는 것일까?), 개념 객체가 아니라면, Service 레이어에 위치해도 되는 것일까?별개로 이 부분에대해서는 개념객체 일 수도 있고 아닐 수도 있습니다 (정의하기 나름이라고 봅니다)주문 수 같은 정보는 중요하지는 않지만 부수적인 개념객체로 볼 수도 있고 그냥 단순한 데이터 객체로 생각해볼 수 있을 것 같습니다할인에 대한 딱지는 만약 금액에 대한 정책이라면 Presentation Layer 에서 처리하는게 좋다고 봅니다!다만 다른 정책에 대하여 할인 딱지를 보여줘야한다면 할인에 대한 개념이 필요한지 부터 검토해서 전략을 만들어볼 수 있을 것 같습니다!모쪼록 답이 되었길 바랍니다! 추가 질문은 편하게 주세요!완강까지 화이팅하시고 완강 후 수강평도 기대하겠습니다!