step2 미션 제출합니다. #400
step2 미션 제출합니다. #400
Conversation
| @@ -255,3 +255,275 @@ docker compose -p kitchenpos up -d | |||
| | 배달을 완료했다. | complete delivery | 배달기사가 주문한 메뉴를 손님에게 전달을 완료했다. | | |||
|
|
|||
| ## 모델링 | |||
|
|
|||
| ### 상품(Product) | |||
|
|
||
| ### 상품(Product) | ||
|
|
||
| #### 상태 |
|
|
||
| #### 상태 | ||
|
|
||
| - 상품명(name) |
There was a problem hiding this comment.
모델링의 용어들을 모두 한글명으로 작성해주셨는데, 영문명으로 변경하거나 혹은 영문명과 한글명을 같이 표현한다면
모델링 문서를보면서 실제로 코드로 옮기는 작업이 조금 더 쉽지 않을까요? 🙂
There was a problem hiding this comment.
사실 이게 조금 고민이였는데, 용어 사전에서는 상품명이지만, 실제 모델에서의 해당 부분은 name (이름) 이 되는거 같아요.
사실 저희는 상품명(product name)이 있고 name은 이름이라고 생각하고 있었는데
혹시 이런 경우에는 좀 어떻게 해야 할지 난감한거 같습니다.
아울러 모델링의 용어들을 모두 한글명으로 작성해주셨는데, 영문명으로 변경하거나 혹은 영문명과 한글명을 같이 표현한다면 이게 어떤 의미인지 좀더 설명이 가능할까요?
There was a problem hiding this comment.
제가 조금 헷갈리게 코멘트를 달아둔 것 같네요. 👀 🙏
예를 들자면 아래와 같이 정의하신 영문명 용어를 같이 표현해주면 나중에 모델링 문서를 코드로 옮기기가 더 쉬울 것 같다는 이야기였어요. 🙂
AS IS
- 상품을 등록할 수 있다.
TO BE
- 상품(
product)를 등록(create)할 수 있다.
| - 상품명은 비속어를 포함할 수 없다. | ||
| - 가격(price) | ||
| - 가격은 필수값이다. | ||
| - 가격은 0원보다 작을 수 없다. |
There was a problem hiding this comment.
사소하지만 이런 케이스는 부정보다는 긍정으로 작성하는게 조금 더 잘 읽힐 것 같아요. 🙂
| - 가격은 0원보다 작을 수 없다. | |
| - 가격은 0원 이상이어야한다. |
| - 상품을 등록할 수 있다. | ||
| - PurgomalumClient를 통해 비속어 검증을 한다. | ||
| - 상품 가격을 변경할 수 있다. | ||
| - 메뉴의 가격이 메뉴에 속한 상품 가격의 합보다 클 경우 메뉴는 숨겨진다. |
There was a problem hiding this comment.
용어사전에서는 미노출한다 혹은 숨김 메뉴와 같은 용어를 사용하셨는데 여기서는 숨겨진다와 같은 용어를 쓰고있어요.
메뉴를 '미노출하면' '숨김 메뉴'가 된다고 볼 수 있을 것 같은데, 이 부분도 용어를 통일시켜보면 어떨까요? 🤔
There was a problem hiding this comment.
또한 사소할 수 있지만 용어 사전으로 정의한 용어라면 (백틱)을 사용하여 한눈에 알아볼 수 있도록 표시해주는 것도 문서를 조금 더 읽기 쉽게 만들어줄 수 있을 것 같네요. 🙂
| - 포장하기와 배달하기의 주문 내역 수량은 0 이상이여야 한다. | ||
| - 가격(price) | ||
|
|
||
| ### 주문(Order) |
There was a problem hiding this comment.
용어 사전처럼 주문 유형별로 컨텍스트를 분리해서 모델링해보면 어떨까요? 🙂
| - 주문 내역은 필수값이다. | ||
| - 주문 내역은 1개 이상이여야 한다. | ||
| - 배달 주소(deliveryAddress) | ||
| - 배달하기 주문인 경우에는 핋수값이다. |
There was a problem hiding this comment.
오타인 것 같아요. 👀
| - 배달하기 주문인 경우에는 핋수값이다. | |
| - 배달하기 주문인 경우에는 필수값이다. |
| - 먹고가기 주문인 경우 해당 주문 테이블의 모든 주문이 완료된 경우에만 테이블을 치울 수 있다. | ||
| - 주문을 조회할 수 있다. | ||
|
|
||
| ```mermaid |
There was a problem hiding this comment.
용어 사전처럼 주문 유형별로 컨텍스트를 분리해서 모델링해보면 어떨까요? 🙂
위의 피드백을 반영한다면 이 부분도 변경이 필요하겠네요! 👀
| } | ||
| ``` | ||
|
|
||
| ## 정책 |
There was a problem hiding this comment.
정책을 따로 정리해주셨군요? 👍
단지 조금 고민해볼 부분은 주문 유형별로 컨텍스트를 분리해서 속성, 행위를 모델링했다면
정책으로 정리한 요소들은 각 컨텍스트의 속성에서 다룰 수 있었을 것 같다고 생각하는데, 세윤님은 어떻게 생각하시나요? 🙂
이번에도 잘 부탁합니다.