🚀 2단계 - 모델링 하기

[hoon25]

안녕하세요 리뷰어님 2단계도 잘부탁드립니다🙇‍♂️

• 기존 요구사항들의 문장을 다듬고 속성/기능/정책으로 분류
• 상대적으로 복잡도가 높다고 생각하는 주문상태 흐름에 관련한 다이어그램을 추가

두가지 작업을 메인으로 진행했어요. 추가적으로 반영해야 하는것 이 있으면 리뷰 남겨주세요!

[HackSung]

빠르게 다음단계를 진행해 주셨군요! 👍
본격적인 리뷰전에 한가지 짚고 넘어가야 할 부분이 있어 코멘트 남겨드렸습니다.
확인하시고 함께 고민해 보면 좋을 것 같아요 😄

[HackSung]

모델링 하기 요구 사항에 아래와 같은 내용이 적혀있는 것 처럼
이번 단계는 창훈님이 이전 단계에서 작성하신 요구 사항과 용어 사전을 기반으로 모델링 하기미션이라
이 위치에 모델링 내용을 새로 작성해 주셔야 할 것 같아요. 😅
다시 정리해 주시면 본격적으로 리뷰 시작할게요!

키친포스의 요구 사항과 용어 사전을 기반으로 README.md에 모델링을 한다.

이미 알고계시겠지만 모델링하시면서 새롭게 도출되거나 변경된 사항들은
기존 요구 사항과 용어 사전에도 계속해서 반영하시면 됩니다.

[HackSung]

창훈님이 생각하시고 계시는 모델링이란 무엇인지 생각을 나눠줄 수 있으실까요? 😄
모델링에 대한 제 생각을 먼저 말씀드리자면
정의된 요구사항과 용어를 기반으로 필요한 도메인 객체의 속성과 상태를 구성해 보고
객체 간의 관계와 행동을 정의해 보는 작업이라 생각합니다.
더 단순하게 표현하자면 비즈니스 요구사항을 소프트웨어로 구현하기 위한 추상화 및 구체화 과정 같아요.
그래서 모델링 하실 때 사용 용어를 미션설명 예시에 나와 있는 패턴처럼 영문변수명 형태로 대체하거나 같이 적어주면
구현단계에서 좀 더 편하게 진행하실 수 있을거에요.

[hoon25]

모델링 하기를 어떻게 진행해야할지 미리 질문을 할 걸 그랬네요😢
제가 생각한 모델링도 리뷰어님과 비슷하게 현실세계의 문제를 소프트웨어에 맞게 추상화과정이라고 생각합니다.

리뷰어님이 상세하게 적어주신 도메인 객체의 속성과 상태, 객체간의 관계와 행동을 정의 부분도 신경써서 작성해보았어요. 친절한 설명 감사합니다.🙏

[hoon25]

빠른 리뷰해주셔서 항상 감사합니다 🙇‍♂️🙇‍♂️

추가적으로 궁금한부분이 있는데요. 모델링은 개발자들과 공유한다고 생각하고 작성해도 괜찮을까요?

[HackSung]

추가적으로 궁금한부분이 있는데요. 모델링은 개발자들과 공유한다고 생각하고 작성해도 괜찮을까요?

넵! 맞습니다.
모델링 공유를 통해 팀 전체가 개발시 효과적인 커뮤니케이션과 일관성을 유지할 수 있다고 생각합니다.

[HackSung]

미션진행 잘 해 주셨습니다. 👍
같이 고민해 볼만한 코멘트들을 남겨드렸으니 확인 부탁드릴께요~ 🙏

[HackSung]

사소하지만 전체적으로 용어는 백틱문자(`) 감싸서 쉽게 구분되어 보이게 하면 좋을 것 같아요.

Suggested change

	- Product는 식별자와 price, name을 가진다.
	- `Product`는 식별자와 `price`, `name`을 가진다.

[HackSung]

quantitiy외에도 MenuProduct를 구성하는 속성이 더 있지 않을까요?

[hoon25]

매핑테이블 성향을 가진 속성들에 대해서도 모델링에 전부 추가 완료했어요!

[HackSung]

접수보다는 수락이라는 표현을 사용해보는 것에 대해 어떻게 생각하세요?

[hoon25]

더 직관적인 용어로 보이네요!! 반영완료했어요👍

[HackSung]

DeliveryAgency를 호출할때 어떤 정보들을 넘겨야 하는지도 기술해 주면 좀 더 명확해지지 않을까요?

[hoon25]

반영 완료했습니다!

[hoon25]

+) DeliveryAgency의 호출내용을 적다보니 생긴 궁금증

리뷰어님은 DeliveryAgency에 필요한 값들을 찾는 책임을 두 클래스중 어디에 두실 것 같나요?

• DeliveryAgency의 구현체
• DeliveryAgency를 호출하는 곳(지금은 DeliveryService)

좀 더 심플하게
requestDelivery(UUID orderId) vs requestDelivery(UUID orderId, BigDecimal amount, String deliveryAddress);의 고민이라고 볼 수 도 있을 것 같네요.

---

제 생각을 먼저 적어보자면 저는 DeliveryAgency의 구현체에서 하는 것이 적절하다 생각했어요.

DeliverAgency가 여러 외부 서비스의 인터페이스라면 각 외부 서비스들이 요구하는 스펙이 각각 다를 것이고,OrderService에서 orderId만 넘겨주는게, OrderService와 DeliveryAgency의 결합도를 낮추게 된다는 장점이 있다고 생각했어요.

[HackSung]

+) DeliveryAgency의 호출내용을 적다보니 생긴 궁금증

리뷰어님은 DeliveryAgency에 필요한 값들을 찾는 책임을 두 클래스중 어디에 두실 것 같나요?

• DeliveryAgency의 구현체
• DeliveryAgency를 호출하는 곳(지금은 DeliveryService)

좀 더 심플하게 requestDelivery(UUID orderId) vs requestDelivery(UUID orderId, BigDecimal amount, String deliveryAddress);의 고민이라고 볼 수 도 있을 것 같네요.

제 생각을 먼저 적어보자면 저는 DeliveryAgency의 구현체에서 하는 것이 적절하다 생각했어요.

DeliverAgency가 여러 외부 서비스의 인터페이스라면 각 외부 서비스들이 요구하는 스펙이 각각 다를 것이고,OrderService에서 orderId만 넘겨주는게, OrderService와 DeliveryAgency의 결합도를 낮추게 된다는 장점이 있다고 생각했어요.

오호! 흥미로운 토론 주제가 될 수 있을 것 같아요! 🔥
먼저 창훈님의 의견은 충분히 타당성 있고 합리적이라 생각합니다! 👍

하지만 저의 경우는 단일 책임 원칙(SRP)의 관점에서 들여다 보았을 때
DeliveryAgency를 호출하는 곳에서 필요한 값들을 찾는 책임을 두는 것이 더 적절할 것 같다는 의견입니다.
주 이유는 DeliveryAgency는 외부 배달 서비스에 대한 단순한 인터페이스 역할을 하는 것에 집중하는게 좋을 것 같아서요.
외부 서비스 호출에 필요한 데이터를 직접 조회하는 로직을 포함하게 되면
DeliveryAgency는 배달 서비스 호출이라는 본연의 책임 외에 데이터 조회라는 또 다른 책임을 지게 되겠죠.
DeliveryService는 배달 처리라는 비즈니스 로직을 담당하니 배달 요청에 필요한 정보에 접근하기 더 쉬울 것 같고
수집한 정보를 DeliveryAgency에 전달하는게 자연스러워 보여요.
유연성 측면에서도 만약 DeliveryAgency 구현체 내부에서 필요한 정보를 조회하도록 한다면
정보 조회 방식이 변경될 때마다 (예: 다른 데이터 소스에서 조회, 조회 로직 변경 등) DeliveryAgency 구현체를 수정해야 합니다.
반면에 DeliveryService가 필요한 정보를 준비하는 경우 정보 조회 방식 변경은 DeliveryService 내에서만 이루어지므로 DeliveryAgency는 변경에 영향을 받지 않을 것 같아요.

창훈님은 DeliveryAgency가 여러 외부 서비스의 인터페이스라면 각 서비스의 스펙이 다를 수 있고
OrderService에서 orderId만 넘겨주는 것이 OrderService와 DeliveryAgency의 결합도를 낮춘다고 하셨는데
DeliveryAgency는 각 서비스의 차이점을 캡슐화하여 DeliveryService에게 일관된 인터페이스를 제공하는 역할을 해야 할 것 같아요.
DeliveryAgency 내부에서 각 서비스에 맞는 데이터 변환이나 처리를 수행할 수 있지만
데이터 조회 자체를 DeliveryAgency의 책임으로 보는 것은 과도한 것 같아요.
또한 OrderService에서 orderId만 넘겨주는 것이 결합도를 낮춘다는 점은 일부 동의하지만
이는 DeliveryAgency가 특정 도메인(Order)에 강하게 결합되는 것을 의미할 수 도 있을 것 같아요.
그리고 DeliveryService가 필요한 정보를 직접 전달하는 방식의 경우
DeliveryAgency가 더욱 일반적인 목적을 수행하도록 만들어
OrderService 외 다른 서비스에서도 재사용될 가능성을 높일 수 있을 것 같아요.
물론 상황에 따라 창훈님의 의견이 더 적절할 수도 있어요!
예를 들면 DeliveryAddress를 DeliveryService에서 접근하기 어렵거나
DeliveryAgency 내부에서 최적화된 방식으로 데이터를 조회할 수 있는 특별한 경우에는
창훈님의 의견이 더 합리적일 수 있습니다.
하지만 저는 SRP 원칙을 고려했을 때 데이터를 준비하는 책임은 DeliveryService에 있는 것이 더 바람직하다고 생각했습니다.
에고 말이 너무 길어졌는데 추가 의견 있으시면 언제든지 말씀해 주세요. 😄

[HackSung]

뭔가 살짝 부자연스러운 문장처럼 느껴지는데 TakeOutOrder라는 주문 유형이 있다는 걸 나타내신 걸까요?
그렇다면 OrderType은 ○, ○, ○ 중 하나다. 라는 식으로 전체를 나열해 주는 건 어떨까요?

[hoon25]

두가지 마음이 섞여서 저렇게 표현이 되었네요😢 분리해서 나열했어요!

[HackSung]

제약이 없는 것을 굳이 명시할 필요가 있을까요? 🤔

[hoon25]

#469 (comment) 와 동일하게 분리해서 나열했어요!

[HackSung]

수업시간에 바운디드 컨텍스트의 개념을 배우셨고 다음 미션도 바운디드 컨텍스트 중심의 패키지 구조로 리팩터링하기 인데요.
혹시 주문 도메인을 주문의 유형에 따라 바운디드 컨텍스트로 나눠 보는 건 창훈님은 어떻게 생각하세요? 🤔
리뷰이분들 중에서도 의견이 분분한데 주문 유형은 달라도 공통되는 부분이 많아서 유형별로 나누는 것은 좀 과도한 것 같다고 하시는 분도 있고
주문 테이블은 홀 주문에서만 필요하고 배달 관련은 홀 주문이나 포장 주문에서 전혀 사용하지 않는 이런 부분때문에
나누는게 더 좋아 보인다는 분도 있거든요.

[HackSung]

피드백 훌륭하게 반영해 주셨어요! 👏
창훈님이 제게 주신 질문의 답변과 저도 창훈님께 드리는 질문을 남겨드렸는데요.
확인하시고 PR주시면 바로 머지하도록 하겠습니다! 😄