블로그에 정리

안녕하세요 지헌님!아무래도 강의의 예제 및 코드는 유료 구매 컨텐츠에서 꽤 중요한 부분이라 직접적으로 블로그에서 사용하시는 것은 어려울 듯 합니다😭이 점은 양해 부탁드립니다!오히려 지헌님이 강의를 통해 생각하셨던 것들을 풀어내시는 방향으로 블로그를 작성해보시면 어떨까 싶습니다!제가 강의로 전달하고 싶었던 것 또한 지헌님의 생각하는 힘이 얼마나 커지는지가 더 중요한 것이라고 생각했으니까요!

섹션2에서 Product와 Category 간 개념 정리에 대해 질문이 있습니다 !

우용님 아주 흥미로운 질문 감사드립니다!우선 Product 와 Category 관계에서 상/하위를 비교해서 말씀드렸지만 정확히하면 개념도는 평면도 개념이기에 위상으로 비교하는게 큰 의미는 없습니다 (상/하위란 것도 둘의 연관성과 별개로 거리감을 보여주는 것이라고 이해하시면 좋습니다)더 중요한건 개념간의 거리/연관도 그리고 더더 중요한건 개념들의 중요도(우선도) 정도라고 볼 수 있을 것 같습니다적어주신 의문 중 먼저 다시 짚어봐야하는 부분은 ProductCategory 는 Category 에 대한 부가정보라고 볼 수도 있고, 아닐수도 있습니다왜냐하면 ProductCategory 은 Product 와 Category 를 모두 알고 있기 때문입니다(개념도에서 ProductCategory -> Product 화살표가 없는 것은 같은 격벽 안에 있기 때문입니다)그러므로 ProductCategory 는 사실 어디에도 존재할 수 있습니다, 반대로 클래스 이름도 CategoryProduct 으로 해도 불가능한 것은 아니라는거죠그렇다면 무엇을 기준으로 개념도를 그린 것 일까요?제가 개념도를 그리는 기준은 일반적으로 중요도 입니다, Category 는 이번 강의 기준으론 사실 최종 개념도에 생략 될 정도로 중요한 개념이 아닙니다반면에 Product 는 중심에 있는 개념입니다, 그만큼 지금 우리가 만드는 서비스 기준으론 Product 중심으로 비즈니스가 돌아가는 부분이 있다는거죠 그 관점에서 ProductCategory 같이 모호한 친구를 어디 둘것인가에 대해서는결국 "카테고리가 연결 된 상품 정보 vs 상품이 연결 된 카테고리 정보" 이런 상황인 것이고 여기서는 어디에/어떤기준으로 일관적으로 무게를 둘것인지 선택만 필요할 뿐인것이죠! 사실 Product 와 Category 는 서로 관심도 없고 굉장히 먼 사이입니다 (상/하위를 떠나서 서로 알고 싶어하지 않고 관심도 없고, 거리가 먼 상태)마치 레이어 처럼 상/하위로 나타내기 불가능한 상태이기도합니다Product 가 Category 가 있어야지만 생성 될수있다던가Category 가 Product 가 있어야지만 생성 될수있다던가위와 같은 상황이 아니니까요!그래서 개념도 상으로도 "Product 하위에 Category 가 있다" 라고 이해하시면 안 됩니다!(다만 우용님만의 새로운 개념도 그리기 기준을 만드신다면 가능한 부분입니다! 강의 기준으로 의도한 내용은 그렇지 않습니다는 얘기입니다ㅎㅎ)대략 이런 느낌이 존재하는거죠Product 와 Category 는 서로 관심도 없다Product 와 Category 는 서로의 존재도 모른다요구사항의 의해 Product 마다 Category 가 존재 할 수있어야한다, 그런데 Product 는 이 사실을 알고싶지않다현재 우리 서비스에서 Product 는 1급 개념현재 우리 서비스에서 Cateogry 는 9급 개념우리 비즈니스의 개념을 정리해보니 Product 중심이기에 중심 개념 기준으로 개념을 모아두었다 +@ 사실 강의 초반 설명을 위해 개념도에 그려두었지만 ProductCategory 수준은 개념도에 그리지 않는게 맞습니다! 별로 중요한 개념은 아니거든요!용어적으로 제가 혼동을 드린 부분도 있어보여서 참고하셔서 한번 더 생각 해보시면 좋을 것 같습니다!보통 저는 개념의 급수라고 표현을 하기도하는데 상/하위보다는 1급개념, 2급개념 이런식으로 관리하는 것 같습니다!(관련 제 유튜브 영상 : https://www.youtube.com/watch?v=H6f0VfbXcb4)개념도는 그리기 나름이지만 제 경우는 평면으로 그리기에 위상은 없는 형태라고 봐주시면 됩니다! 더 궁금하신거나 이해가 더 필요하신 부분이 있다면 편하게 답글주세요!누구나 생각해볼법한 흥미로운 질문 감사드립니다 우용님! 남은 강의도 즐거운 시간 되시고 완강 후 수강평 부탁드려요!

도메인 계층에서 Page 사용 질문

아주 흥미로운 질문이네요 😄궁금하신 것들을 답변드리기 전에 아래 내용에 대하여 생각해보신 후 생각을 답글로 주시면 제 의견을 전달드리겠습니다!지금 우리 코드에서 도메인 계층이란 어디에 존재하는 것이고 무엇을 의미할까요?순수한 로직이란 무엇을 의미하나요?예제 코드에서 Page 클래스 는 순수한 상태가 아닌걸까요? 아니라면 순수한 상태는 무엇인가요?유사하게 OffsetLimit 클래스 는 어떤 상태일까요?도메인 계층이라고 생각하시는 곳에 Page 에 대한 코드가 아예 없어야면, API 요청을 받고 나서 어떻게 쿼리 실행 하는 코드까지 파라미터로 전달을 할 수있을까요?"도메인 계층에서 Page에 관한 DTO를 하나 생성하고 스토리지 모듈에서 해당 DTO로 반환하게 코드를 작성하였습니다" 스프링 의존성을 얘기해주셨는데, 그럼 *Service 에서 JPA Repostiory 를 쓰는 것은 의존이 없는 상태일까요? 또 순수한 상태일까요? 충분히 생각해보시고 댓글 기대하겠습니다! (생각해봐도 잘 모르겠는건 모르겠다 해주세요! 😄)

이상적인 공부 방법

공부만이살길님 아주 핵심적이고 좋은 질문 감사드립니다!!제가 생각한 이상적인 이 강의 활용법은 아래 느낌입니다!+ 일단 각 섹션의 학습을 쭉 순서대로 정주행한 다는게 기본이라고 생각합니다!'요구사항 느끼기'를 다 본 후 잠시 강의를 멈추고 내 생각을 정리해보기요구사항에서 더 필요한 부분이나 제가 정의한 것과 다르게 생각하는 부분이 있는지애초에 기획이 잘못 됬거나 아쉬운 부분이나 누락은 없는지 등등 충분히 생각 해보기* 우리가 기획자는 아니지만 기획을 통해 비즈니스를 구현을 하는 역할로써 구현할 대상을 충분히 이해했는지 시간을 갖는 목적요구사항에 대한 생각 정리가 끝났으면, '코드 느끼기' 전에 나는 이렇게 구현할 것 같다 라고 생각해보기 OR 직접 구현해보기 (사실 이게 제일 좋다고 생각합니다ㅎㅎ.. 진짜 코드아니더라도, 상세한 구현 없이 껍데기만 있는 sudo 코드라도 작성해보는 느낌이요!)'코드 느끼기' 시청 후 내가 생각한 부분과의 차이점, 아쉬운점 등등 한번더 곱씹기'개념 정리' 를 통해 '요구사항 느끼기'와 '코드 느끼기' 를 한번더 생각해보기추가로 우리가 요구사항과 다르게 코드 단에서 개념을 정의했거나, 우리 소프트웨어에서 어떤 부분이 더 중요한 개념이고 핵심 개념인지에 대해서 한번 더 생각해보기나름대로 요구사항과 코드에 대한 생각이 있었다면 직접 나만의 개념도를 그려보기 대략 이렇게 활용하면 이 강의를 200% 활용할 수 있다고 생각합니다!사실 위의 내용은 제가 저년차 개발자 때 실무를 할때 훈련 했던 방법이고 지금도 가끔 특정 사이드 프로젝트 개발 시에 활용하는 방법 중 자주 쓰는 방식이기도합니다!이 방식이 무조건 정답은 아니지만 권장 할 정도는 된다고 봐주시면 좋은 것 같고모쪼록 방식 상관없이 최대한 매 수업 중과 사이에 생각을 많이 해보시는걸 추천드립니다!추가로 비판적인 자세로 강의에서 얘기하는 요구사항이나 코드가 정답이라 생각하지마시고 본인의 생각으로 반박해보는 느낌으로 강의를 들으시면 더욱 좋을 것 같습니다! 알찬 질문 감사드리며 완강 까지 화이팅입니다! 수강평도 기대하겠습니다!

Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여..

우선 첫 질문 감사합니다! 너무 기쁩니다!후후.. 제 의도와 일치하게 고민이 생기기 시작하셨다니 아주아주 기쁜 마음입니다 +_+!저는 결국 여기서 우리가 팀이라고 가정한다면 방향과 기준을 선택해야한다고 봅니다!(사실 컨트롤러에서 조합하는게 이질적이고 어색하게 느껴지신다면 일반적으로 대부분 사람들이 그렇게 느낄 것이라서 그렇게 느끼시는게 맞습니다 +_+ 후후후... (계획대로...))적어주신 것과 같이 QuestionPaymentService 가 너무 많은 것을 알고 있는 형태라고 보여집니다그렇다면 우리가 여기서 선택 할 수있는 전략은 아래와 같은 것들이 있습니다 (당장 생각나는 것들만 적었습니다 ㅎㅎ)1안. Controller 에서 Service를 조합한다2안. QuestionPaymentService 안에 의존되어있는 컴포넌트들을 더 '개념화'하여 컴포넌트를 한 단계 더 '응집' 시킨다3안. Controller 와 Service를 연결해주는 단계(ex] 레이어)을 구성한다저는 보통 2안을 하향식 (Service 밑으로 응집을 내려서 하위 컴포넌트를 구축), 3안을 상향식 (Service 위로 상위 영역을 구성해서 구축) 이라고 부르긴합니다만--위와 같은 안에서 위고잉업님은 어떤 전략을 선택하실 것 같으신가요?몇가지 생각할 거리를 더 던져드리면....1안 고민서비스가 한두개에선 나쁘지 않아보임, 근데 많아지면..? 흐름이 여기 보이는게 맞나..?2안 고민 어느 단위로 응집 시켜야하지?, 모든 비즈니스 로직에서 컴포넌트 응집이 생기지는 않을텐데 (조회성나 단순한 기능에서는 여러 개념이 묶이는 경우가 적으니까..?), 그렇다면 '응집 된 컴포넌트'를 만드는 기준은 어떻게 해야하지..?무엇을 기준으로 응집 시켜야하지?3안 고민그 구분을 '레이어'라고 지칭한다면 전체 프로젝트의 통일을 해야하는 느낌인데... 모든 비즈니스가 이 '레이어'가 필요하지 않은데 그럼 선택적으로 구성해야할까........?레이어(컴포넌트 간의 경계 영역)란 무엇일까.....!?사실 저 중에 제가 제일 선호하는 안은.......... (더보기) 제 선호 안은 위의 내용을 생각해보신 후의 위고잉업님의 '결론 or 질문'을 다시 달아주시면 답변 드리겠습니다 :p)

동일 계층의 애플리케이션 서비스가 서로의 인터페이스를 사용하여 의존하는 경우에 대해서

안녕하세요 :D 토비님에게 해당 질문에 대해서 전해들어서 저도 짤막히 생각을 달아봅니다🙂그 전에 먼저 오래 된 글인데도 봐주시고 언급까지 해주셔서 감사합니다!핵심 질문에 대한 얘기를 먼저 해보면 (다만,, 제가 현실이 너무 바빠서 강의를 아직 못 봤습니다ㅜㅜ 이 점 양해를... 토비님 사랑합니다)같은 계층에서 인터페이스 포트를 통해서 호출하는 것은 괜찮을까 고민이 들었습니다. 적어 주신 질문 글의 맥락으로 보면 저런 케이스의 호출에 대한 것은 전략을 정할 수 있는 영역으로 보입니다. 코드를 못 봤지만 맥락 기준으론 허용이 충분히 가능하다고 봅니다, 특히 구현체가 아닌 인터페이스 기반이라면 더욱 허용이 쉬워진다고 생각합니다. 다만, 이런 호출의 기반에는 올바른 개념(도메인)의 정립과 아래 설명한 '격벽'(단어와 상관없이 개념간 경계 영역 의 대하여 고민이 선제 되어야한다 생각합니다.(단순히 해당 규칙을 허용하는 순간 잘못 된 개념끼리도 엮일 수 있으니까요, 물론 이 부분도 코드 리뷰나 도메인 리뷰가 철저하다면 괜찮겠지만요)[해당 글의 '레이어'에 대하여]과거의 제 글에서 ‘레이어’라고 소개 된 부분은 사실 '레이어드 아키텍처' 를 강조하고 설명하고자 한 글은 아닙니다사실 이런 오해(?) 때문에 저는 요즘 ‘격벽’(2024인프콘 에서 발표한..) 이라는 용어를 더 많이 쓰는데요 결국 다양한 관점이 있지만 공통 분모로 개발자들이 말하는 것은 우리가 소중히 여겨야하는 부분(그걸 '개념'이라 부르건 '도메인'이라 부르건)을 어느정도 의존시키고, 어떻게 협력시킬지에 대하여 어떤 전략을 가져갈지 결정하는 것이 핵심인 것 같습니다. 저는 이런 측면에서 레이어드 / 포트&어뎁터 이렇게 무 자르듯이 아키텍처 결정하고 나누는 것은 선호하지 않습니다제 기준에서는 잘 만든 레이어드가 진화하면 건강한 도메인이 나올 수 있고 필요에따라 포트&어뎁터로 진화하는 것은 상당히 쉬운 일이라고 생각하기 때문입니다. 추가로 해당 글의 비즈니스로직 + 레이어 챕터의 핵심은 토비님이 적어 주신 것이 정확합니다.상세 구현 로직은 잘 모르더라도 비즈니스의 흐름은 이해 가능한 로직이어야 한다. 제가 여러 조건 때문에 현재 강의를 찍을 순 없지만, 추후에 이런 내용을 종합하여 한번 강의로 찍어보고 싶네요 :D [동일 레이어 참조 허용 규칙 관련]저도 재민님께서 저렇게 제안하신 이유는 아마 설계의 단순성을 통해서 여러사람이 같은 영역을 작업하기 편하게 한 것 같다는 생각이 듭니다.MASKUN 님이 답변 주신 것 처럼 해당 글의 저 규칙은 특정 현실 상황에 상당히 유리한 면이 있습니다.개발 팀원 수개발 팀원들의 역량 수준개발 팀원들을 코드 리뷰/코칭 해줄 수 있는 여유가 있는가각개전투로 인당 프로젝트를 1개씩 해야하진 않는가 등등 개발할때에는 현실적인 상황을 종합적으로 고려해서 해야합니다, 그렇다면 저 글의 최대 효율은 언제 나올까를 생각해보면 대부분의 조건이 열악한 상황에서 최선의 효율정도 까지는 보장이 됐던 것 같습니다 .(온전히 제 경험 기준입니다 :D )최악의 경우로 말하면... 누군가 코드를 망쳐놔서 그로인해 회사에 심각한 문제가 있을때, 제가 직접 가서 해결해야하는 상황에서 그나마 최선의 코드를 만날 수 있습니다. 😅 모쪼록 좋은 질문과 토비님의 깔끔한 답변과 질문자 분의 정리까지 즐거운 글 같습니다 :D제 글 뿐만 아니라 토비님의 강의에서도 장점과 단점 트레이드 오프에 대하여 충분히 이해하시고 처해계신 상황에 맞는 전략을 결정해서 펼쳐나가보시길 바라겠습니다. 다양한 관점을 융합해서 시도해보고 실험하다보면 MASKUN님 만의 새로운 전략 및 철학이 탄생할 수 있을 것이라고 생각하고, 저는 그런 것이 수 많이 이미 정립된 이론 보다 멋진 것 이라고 생각합니다 다시 한번 알찬 질문과 글 언급 감사드립니다 :D 추가로 아래 내용은 저는 잘 만들면 이런 문제는 없다 라고 생각하긴 하는데ㅎㅎ (그런 문제가 생기기 쉬운 것은 팩트이긴합니다) 이건 저도 추후에 코드로 보여줄 수 있으면 좋을 것 같네요!도메인 모델의 빈혈을 유발할 수 있겠다는 생각이 드네요.

Business Logic!

외부에서 주입받도록 분리한 로직들이 의미하는 부분이 어떤 로직을 말하시는 건지 애매한 것 같습니다! 외부 라이브러리나, 외부 통신을 위한 클라이언트를 의미하시는 걸까요? 그렇다면 Data Access Layer 에 해당합니다!

Business Layer 인자 처리

1. 클라이언트로부터 전달되는 presentation layer 에서 바로 전달받는 것을 기대하셨는지2. 아니면 리팩토링 전과 같이 payRequest 로 controller에서 전달 받은 뒤 다른 layer (business 혹은 presentation) 에서 dto 로 변경한 뒤 businessPay() 메서드를 호출하여 인자를 입력해주는 것을 기대하셨는지3. 아니면 다른 방법으로 진행이 되는지2번입니다!PayRequest 가 Presentation Layer 에 있는 상황에서, Business, Implement Layer 에 파라미터로 넘어온다는 것 자체가 레이어를 지키는 규칙을 위반하는 '레이어 역류' 에 해당 되버리기 때문입니다. 그래서 흐름 상으로 보면 외부 랑 가장 가까운 Presentation Layer 에서 PayRequest 를 받고 Presentation Layer 에서 Business Layer 로 가기전에 Business, Implement Layer 의 객체로 변환을 하고 넘겨준다고 이해하시면 될 것 같습니다. 제 유튜브에도 있을 것 같은데 저도 못 찾겠네요;; 관련해서는 예전에 제가 발표했던 내용을 참고해 보시면 좋을 것 같습니다!https://youtu.be/RVO02Z1dLF8?si=Wj4ZhsYESDE2T5xS&t=508 질문 감사드립니다!

모듈에 대한 단방향 의존

제가 생각하는 구조는 1번 코드와 2번 코드 모두 아닙니다.이 강의 설명 기준에서는 API 모듈이 자체적으로 디비 접근 의존성을 갖지 않고 DB 모듈을 사용하는게 핵심입니다.그렇기에 인터페이스 없이 API 모듈이 DB 모듈을 의존하고 있는 형태가 전부 입니다.(강의 중간에 인터페이스를 맞춘다는 얘기는 메소드 시그니처를 맞춘다는 의미로 이해하시면 됩니다.)그래서 대략 이러한 구조라고 보시면 될 것 같습니다.// Payments-API 모듈 //// 의존성 implementation(project(":storage:db-core")) //// 코드 class PaymentAppender(val paymentRepository: PaymentRepository){ fun append(user: User, payment: NewPayment): Payment { // ... 중략 } } // db-core 모듈 //// 의존성 implementation(project("...:spring-boot-starter-data-jpa")) /** * 의존성이 변경된다면 * implementation(project("...:hyper-persistence")) **/ //// 코드 class PaymentRepository( val paymentJpaRepository: PaymentJpaRepository /** * 의존성이 변경된다면 * val paymentHyperRepository: PaymentHyperRepository **/ ){ fun newPayment(paymentPersist: PaymentPersist): PaymentPersistResult { val saved = paymentJpaRepository.save(paymentCommand.toEntity()) /** * 의존성이 변경된다면 * val saved = paymentHyperRepository.insert(paymentCommand.toEntity()) **/ return saved.toResult() } } PaymentDB, PaymentDB2 가 별도 모듈이 있는게 아니라, DB-Core 안에서 변경을 대응하는 관점입니다.--소프트웨어는 단계적으로 진화해야 하기 때문에 이 강의에서는 초반 단계 정도의 기본적으로 생각해 볼거리를 중심으로 설명하고 있으므로 완전한 예제가 적절히 나오지 않습니다.초반 단계 프로젝트 구조는 https://github.com/team-dodn/spring-boot-kotlin-template 를 참고하시면 됩니다. 실제 더 진화한 인터페이스(코드 상에서 쓰는 Interface를 의미)와 구현 방향성 관련해서는직접적으로 설명 및 표현하고 있지 않지만, 좀 더 진화된 기준의 구조를 참고하시려면 아래 영상의 후반 부 모듈 구조에 대한 걸 참고하시면 좋을 것 같습니다.https://youtu.be/RVO02Z1dLF8?si=FQdWoLdoBntwTfFS 또 이 아래 영상에서도 참고하실 부분이 있을 것 같습니다https://youtu.be/p5ZMF2bpE6A?si=EE4JB5X2h6HS4F18질문 남겨주셔서 감사합니다 :D