강의

멘토링

커뮤니티

인프런 커뮤니티 질문&답변

worldbright0님의 프로필 이미지
worldbright0

작성한 질문수

제미니의 개발실무 - 커머스 백엔드 기본편

코드 느끼기

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

해결된 질문

작성

·

43

1

안녕하세요!~!

 

  1. 이건 주문 뿐 아니라 다양한 개념에서도 할 수 있는 질문인 것 같은데요~! OrderController 에서 요청을 처리하기 위해 어쩔 수 없이 cartService 를 알고 의존하고 있는데 (개념격벽에서는 차단), 개념간 격벽의 관점에서 OrderController는 order 에 관한 개념이 아닌 것인지 궁금합니다.

    1. Controller 단계에서 여러 Service를 조합하는 코드 스타일로 작성하셨다고 했는데, 만약 Controller 에서는 깔끔한 하나의 OrderFacade(?) 의 메서드만 호출하고 Facade 안에서 여러 서비스를 조합해 기능을 수행한다고 했을 때, 이 OrderFacade 는 Order 개념으로 치지 않는 것인지도 궁금해용.

  2. NewOrder 는 Cart 에서 cart.toNewOrder() 로 바로 만들고 있잖아요?



    결론적으로 Cart 가 Order 를 의존하는 방향이 되어 버리는데 혹시 Cart 가 Order 를 의존하는 것을 의도하신 것인지 궁금합니다.

    개념 정리 강의에서 그려주신 그림을 보면

    Product <-- Order
    Product <-- Cart

    이렇게 Product 에 Order 와 Cart 가 의존하고 있는 모습인데, 위에 제가 말씀드린 로직에서는

    Order <-- Cart

    의존 화살표도 추가해야 맞을 것 같은데 혹시 제가 잘못 이해한 것인지 궁금합니다..!

  3. 추가로,

    Product <-- Order
    Product <-- Cart

    이 의존 방향을 그대로 지키려면,,

    cart.toProductWithQuantitys() 로 카트를 프로덕트로 변환 후에
    NewOrder.fromProductWithQuantitys() 로 프로덕트를 오더로 생성하는 것이 의존 방향이 깔끔하게 맞지 않나 생각이 들어용, 혹시 이건 어떻게 생각하시는지 궁금합니다.

    제 생각에는,, 이렇게 복잡해질 바에야 Order 에서 Product 와 함께 Cart도 같이 알고 있는 것이 좀 더 간단해지지 않을까 하네용.. (지금 코드 처럼)

     

 

현업에서 기존 짜파게티 코드 위에서 개발하다 보니,, 의존 방향에 크게 신경쓰지 않고 직관으로만 개발해왔는데요,, (from~~() , to~~() 남발..ㅎㅎ)

제미니님 강의를 들으면서 안일하게 생각하고 있던 부분을 다시 한 번 생각해보게 된 것 같습니다.

항상 감사해요~~

답변 2

0

제미니님의 프로필 이미지
제미니
지식공유자

안녕하세요 질문 감사드립니다!

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


모쪼록 답이 되었길 바랍니다! 완강까지 화이팅입니다!
완강 후 수강평도 기대하겠습니다! 감사합니다!

0

안녕하세요, 인프런 AI 인턴입니다. worldbright0님이 작성하신 질문은 서비스 아키텍처와 개념 간의 의존성에 대한 깊이 있는 고민을 담고 있습니다. 각 객체의 의존 관계를 재정립하여 소프트웨어 아키텍처를 개선하고자 하는 노력이 보여 매우 인상적입니다.

질문에 대한 핵심 주제 요약:

  1. 컨트롤러에서의 의존성 문제: OrderController가 cartService를 의존하는 부분에 대한 의문을 제기하셨습니다. 이 경우 OrderController는 객체 간의 의존성을 나타내며, 이는 여러 서비스가 자연스럽게 조합되어야 하는 상황에서 발생할 수 있습니다. 각 서비스의 협력을 통해 복잡한 비즈니스 로직이 구현되지만, 이로 인해 발생하는 복잡도는 설계의 견고성에 영향을 줄 수 있습니다.

  2. Facade 패턴의 활용: Facade 패턴은 여러 서비스 호출을 하나의 추상화된 인터페이스로 감싸 사용자의 요구를 간편하게 처리할 수 있게 합니다. OrderFacade가 여러 서비스를 조합하여 기능을 수행한다면, 이는 Order 개념으로 이해될 수 있으며, 그 결과 컨트롤러는 더 간결한 코드로 유지될 수 있습니다.

  3. 의존 방향의 문제: cart.toNewOrder() 방식은 Cart가 Order를 의존하게 되어 의존 방향이 불일치할 수 있습니다. 이 문제를 해결하기 위해 개념 간 의존성을 다시 정의하고, 불필요한 종속성을 최소화하는 접근을 고려해야 합니다. 이를 통해 개념 간 결합도를 낮추고 유연성을 높일 수 있습니다.

  4. 대안 제안: Cart가 Order를 직접 변환하기보다는, 각각의 공통된 개념(Product 등)으로 변환 후 처리하는 방식이 고려되었습니다. 이를 통해 의존 방향을 유지하면서도 로직의 단순화를 시도할 수 있습니다.

이를 좀 더 구체적으로 이해하기 위해 관련된 질문들과 답변을 추천드립니다:

  1. Controller에서 비즈니스 로직 흐름이 나타나는 것에 대하여..: 이 질문에서는 Controller에서 비즈니스 로직이 드러나는 문제와 여러 서비스를 조합하는 방식에 대하여 상세히 설명되어 있습니다.

  2. 격벽에 대한 내용을 코드로 표현 시 질문이 있습니다!: 격벽 및 의존성 방향에 관한 구체적인 코드 구현 방법에 대한 다른 학습자들의 질문과 답변이 참고될 수 있습니다.

이 자료들이 질문자님이 고민하고 계신 의존성 문제에 대한 관점을 넓히고 해결의 실마리를 찾는데 도움을 줄 수 있을 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

worldbright0님의 프로필 이미지
worldbright0

작성한 질문수

질문하기