2단계 - 요구 사항 정리 #708
2단계 - 요구 사항 정리 #708
Conversation
JHyunJung
commented
May 30, 2024
JHyunJung
commented
- 메뉴, 메뉴그룹, 주문, 등 도메인 요구사항을 정리 하였습니다.
| - [ ] 메뉴 가격은 변경 할 수 있다. | ||
| - [ ] 변경될 가격은 0보다 작아서는 안된다. | ||
| - [ ] 변경될 가격은 메뉴상품의 합보다 커서는 안된다. |
There was a problem hiding this comment.
실제로 매장에서 나오는 단건 메뉴 인것으로 파악 했습니다.
Menu는 판매 상품입니다.
배달의 민족으로 예를 들면
우리는 양념치킨을 선택하지만
해당 건에 필수 혹은 옵션 사항으로 선택 가능한 사항이 나옵니다.
치킨무, 소스, 치즈볼 등
ex) Product - 양념치킨, 소스, 치즈볼
ex) Menu - 양념치킨 (사용자에게 노출 되는 대표 메뉴)
ex) MenuProduct - 양념치킨 포함, 소스, 치즈볼등 필수 혹은 옵션 사항
물론 해당 코드의 기능과 배달의 민족의 기능은 다르지만
메뉴 표시 방식은 해당 방식과 유사하다고 생각 합니다.
There was a problem hiding this comment.
오! 예시를 포함해주시니까 바로 이해가 되네요!! 👍
요구사항이 요런 예시를 포함시켜주시는 건 어떨까요?
조금 귀찮겠지만, 요런 사소한 배려들이 동료들의 생산성에 큰 영향을 미칠 것 같아요!
README.md
Outdated
| - [ ] 모든 메뉴 그룹을 조회 할 수 있다. | ||
| - 상품 | ||
| - [ ] 상품 등록이 가능하다. | ||
| - [ ] 가격은 팔수이고, 0보다 작아서는 안된다. |
| - [ ] 가격 변경이 가능하다. | ||
| - [ ] 변경될 가격은 필수이고 0보다 작아서는 안된다. | ||
| - [ ] 상품이 들어간 메뉴의 가격이 변경될 상품의 가격 총합보다 커지게 되면 해당 메뉴를 노출시키지 않는다. |
There was a problem hiding this comment.
상품이 먼저 생성되고 그 이후 메뉴가 생성되는 생명주기, 구조를 가질텐데요,
상품의 가격 변경에 따라 메뉴의 전시상태가 변경되는 것을, 상품은 모르도록 하고 메뉴 입장에서 관리하는 건 어떨까요? 😉
어떤 장점이 있을까요?
There was a problem hiding this comment.
Product와 Menu는 다른 리뷰에서 상술한 것처럼 개념과 용도 자체가 다르기에
Product는 상품의 개념적인 의미로서 쓰이고
Menu는 판매하는 상품인지 아닌지로 다루기 때문에
해당 가게에서 Menu를 판매할지 말지, 할인 유무 등 각종 옵션 사항을 적용하기 더 좋을거 같습니다.
There was a problem hiding this comment.
앗! 답변은 잘 해주셨는데 README.md 에는 변화가 없었던 것 같아요 😭
| - 주문 | ||
| - [ ] 전국 도감 번호 1번부터 151번까지의 포켓몬이 무작위로 등장한다. | ||
| - [ ] 포켓몬은 고유의 포획률을 가지고 있다. | ||
| - [ ] 트레이너는 가지고 있는 몬스터볼을 소비함으로써 포켓몬을 잡을 수 있다. | ||
| - [ ] 포획률 = (포켓몬의 포획률 * 몬스터볼 보정 승수 * (레벨 11 이상의 트레이너 레벨 / 10)) * 100 / 255 | ||
| - [ ] 잡은 포켓몬은 닉네임을 지어 붙일 수 있다. | ||
| - 테이블 | ||
| - [ ] 몬스터볼은 고유의 보정 승수를 가지고 있다. | ||
| (몬스터볼: 1.0, 수퍼볼: 1.5, 하이퍼볼: 2.0, 마스터볼: 255) | ||
| - [ ] 주문 등록이 가능하다. | ||
| - [ ] 주문 유형은 필수이다. | ||
| -[ ] 배달, 포장, 매장식사가 있다. | ||
| - [ ] 주문 항목은 필수이다. | ||
| - [ ] 주문 유형이 식사가 아닌경우에는, 수량이 0보다 커야만 한다. | ||
| - [ ] 주문 항목에 해당하는 메뉴가 필수로 있어야 한다. | ||
| - [ ] 메뉴가 노출여부를 확인해야 한다. | ||
| - [ ] 메뉴의 가격과 주문 항목의 가격이 일치해야 한다. | ||
| - [ ] 위 조건들을 만족할 시 주문 항목 리스트에 추가한다. | ||
| - [ ] 새로운 주문을 생성시킨다. | ||
| - [ ] 주문 상태는 Waiting이어야 한다. | ||
| - [ ] 주문 받는 시간은 실시간으로 한다. | ||
| - [ ] 앞에서 만들어진 주문 항목들을 가진다. | ||
| - [ ] 주문 타입인 배달인 경우 | ||
| - [ ] 배달 주소를 필수로 한다. | ||
| - [ ] 주문 타입이 매장식사인 경우 | ||
| - [ ] 현재 사용 가능 테이블이 반드시 있어야 한다. | ||
| - [ ] 사용 가능 테이블이 있다면 해당 테이블에 배정한다. |
There was a problem hiding this comment.
배달, 포장, 매장식사별 요구사항이 뒤섞여있어 조금 보기 힘든 상태인데요,
각각을 서로 완전히 다른 개념으로 생각하고 분리해보는 것은 어떨까요?
주문 유형별로 고민해야할 특이사항(테이블, 배달주소 등)이 각자에게 퍼뜨려지고,
각자에게 유의미한 주문 상태만 가지면서 가독성이 크게 향상될 것 같아요.
추후 코드로 표현할 때도 훨씬 이점이 많겠는데요? 😉
이렇게 저희는 저희가 관심이 있는 부분에 대해서 명확하게 경계를 나누고 분리하는 개념을
'바운디드 컨텍스트' 라고 부르는 것 같아요!
There was a problem hiding this comment.
현재에는 주문 -> 주문유형으로 확장해서 기능을 정리 하였는데
주문 유형을 자체적으로 분리해서 하는게 더 좋을거 같다는 말씀이신가요?
There was a problem hiding this comment.
맞습니다! 관심 경계를 명확히 나눠보심으로서 변화를 느껴보시고,
어떤 장단점이 있는지 같이 고민해보시죠! 😄
| - [ ] 메뉴 가격은 변경 할 수 있다. | ||
| - [ ] 변경될 가격은 0보다 작아서는 안된다. | ||
| - [ ] 변경될 가격은 메뉴상품의 합보다 커서는 안된다. |
There was a problem hiding this comment.
오! 예시를 포함해주시니까 바로 이해가 되네요!! 👍
요구사항이 요런 예시를 포함시켜주시는 건 어떨까요?
조금 귀찮겠지만, 요런 사소한 배려들이 동료들의 생산성에 큰 영향을 미칠 것 같아요!
| - [ ] 가격 변경이 가능하다. | ||
| - [ ] 변경될 가격은 필수이고 0보다 작아서는 안된다. | ||
| - [ ] 상품이 들어간 메뉴의 가격이 변경될 상품의 가격 총합보다 커지게 되면 해당 메뉴를 노출시키지 않는다. |
There was a problem hiding this comment.
앗! 답변은 잘 해주셨는데 README.md 에는 변화가 없었던 것 같아요 😭
| - 주문 | ||
| - [ ] 전국 도감 번호 1번부터 151번까지의 포켓몬이 무작위로 등장한다. | ||
| - [ ] 포켓몬은 고유의 포획률을 가지고 있다. | ||
| - [ ] 트레이너는 가지고 있는 몬스터볼을 소비함으로써 포켓몬을 잡을 수 있다. | ||
| - [ ] 포획률 = (포켓몬의 포획률 * 몬스터볼 보정 승수 * (레벨 11 이상의 트레이너 레벨 / 10)) * 100 / 255 | ||
| - [ ] 잡은 포켓몬은 닉네임을 지어 붙일 수 있다. | ||
| - 테이블 | ||
| - [ ] 몬스터볼은 고유의 보정 승수를 가지고 있다. | ||
| (몬스터볼: 1.0, 수퍼볼: 1.5, 하이퍼볼: 2.0, 마스터볼: 255) | ||
| - [ ] 주문 등록이 가능하다. | ||
| - [ ] 주문 유형은 필수이다. | ||
| -[ ] 배달, 포장, 매장식사가 있다. | ||
| - [ ] 주문 항목은 필수이다. | ||
| - [ ] 주문 유형이 식사가 아닌경우에는, 수량이 0보다 커야만 한다. | ||
| - [ ] 주문 항목에 해당하는 메뉴가 필수로 있어야 한다. | ||
| - [ ] 메뉴가 노출여부를 확인해야 한다. | ||
| - [ ] 메뉴의 가격과 주문 항목의 가격이 일치해야 한다. | ||
| - [ ] 위 조건들을 만족할 시 주문 항목 리스트에 추가한다. | ||
| - [ ] 새로운 주문을 생성시킨다. | ||
| - [ ] 주문 상태는 Waiting이어야 한다. | ||
| - [ ] 주문 받는 시간은 실시간으로 한다. | ||
| - [ ] 앞에서 만들어진 주문 항목들을 가진다. | ||
| - [ ] 주문 타입인 배달인 경우 | ||
| - [ ] 배달 주소를 필수로 한다. | ||
| - [ ] 주문 타입이 매장식사인 경우 | ||
| - [ ] 현재 사용 가능 테이블이 반드시 있어야 한다. | ||
| - [ ] 사용 가능 테이블이 있다면 해당 테이블에 배정한다. |
There was a problem hiding this comment.
맞습니다! 관심 경계를 명확히 나눠보심으로서 변화를 느껴보시고,
어떤 장단점이 있는지 같이 고민해보시죠! 😄
| - [ ] 주문 승인이 가능하다. | ||
| - [ ] 주문 상태가 Waiting이어야 한다. | ||
| - [ ] 주문 타입이 배달인 경우, 주문 항목의 가격과 수량을 곱한 값을 합하여 배달 요청을 한다. | ||
| - [ ] 주문 상태는 ACCEPTED가 된다. |
There was a problem hiding this comment.
주문 항목의 가격과 수량을 곱한 값을 합하여 배달 요청을 한다. 는
사실 배달주문 뿐만 아니라 다른 주문들도 모두 포함되는 내용일텐데요!
어쩌면 레거시 코드가 앞선 개발자의 실수로 잘못 작성되어 있을수도 있겠네요...! 👀
