1단계 - 용어 사전 만들기

[cjcjon]

작업내용

• 요구사항을 토대로 용어 사전 작성
• 같은 팀원분에게 DM을 보냈는데 답장이 없으셔서 우선 혼자 작성하였습니다.

고민사항

요구사항을 토대로 주로 사용되거나 비즈니스적으로 유효한 용어들을 용어 사전에 작성했습니다.
고민되었던 사항은 상품의 이름, 메뉴의 이름처럼 일반적으로 명확한 용어들도 용어 사전에 정의를 해야 하는지 여부였습니다.
저에게만 명확한지 동료에게도 명확한지는 알 수 없어서 적어두긴 했지만 어디까지 용어를 정의해야 하는지 아직 잘 모르겠습니다.

잘 부탁드립니다.

[wlroh]

준수님 안녕하세요 😄

고민되었던 사항은 상품의 이름, 메뉴의 이름처럼 일반적으로 명확한 용어들도 용어 사전에 정의를 해야 하는지 여부였습니다.
저에게만 명확한지 동료에게도 명확한지는 알 수 없어서 적어두긴 했지만 어디까지 용어를 정의해야 하는지 아직 잘 모르겠습니다.

제가 생각했을 때 용어를 정의하는 경우는 바운디드 컨텍스트 안에서 특별한 의미를 가지거나 이해관계자분들과 생각하는 부분이 다를 때 정의한다고 생각해요.
이벤트 스토밍을 진행하셨다면 핫스팟에 있는 부분들도 용어로 정의될 것 같네요

이번 미션을 진행하실 때 페어가 없으셔서 저와 같이 토론하시며 용어를 도출해봐도 좋을 것 같네요 😄

[wlroh]

준수님 안녕하세요 😄
이번 미션을 함께할 노웅래입니다.
미션 고생하셨습니다 👍
코멘트 작성한 것이 있는데 확인부탁드려요!

[wlroh]

예시와 함께 작성해주니 상품 이라는 용어에 대해 더 이해하기 쉬운것 같아요 👍

[wlroh]

용어사전에 보면 메뉴 상품 이라는 용어도 도출해주신 것으로 보여요.
위의 설명만 보면 메뉴는 1개 이상의 상품으로 구성된 주문의 단위로 이해되어서 상품 대신 메뉴 상품 으로 수정해보는 것은 어떤가요?

[cjcjon]

메뉴에 속한 상품은 이미 메뉴 상품으로 용어를 정의했으니 상품 용어보다 메뉴 상품으로 정의하는게 더 정확하겠네요

[wlroh]

주문의 상태중에 등록된 상태는 없는 것 같은데 이것도 용어로 도출해보면 어떨까요?

[cjcjon]

현재 적혀있는 요구 사항에서 사용하지 않는 용어는 따로 정의할 필요가 없다고 생각했었어요.
WAITING 상태는 상태로 존재하지만 요구 사항에는 존재하지 않는데도 정의할 필요가 있을까요?
같이 일하는 팀원끼리 요구 사항으로만 소통하지는 않으니 요구 사항에 없어도 사용 가능한 용어들은 정의해도 될 거라고 생각은 하는데 어떻게 생각하시는지 궁금합니다.

[cjcjon]

아니면 WAITING을 주문이 등록된 상태라고 보면 될까요?
생각해보니 주문의 등록은 공통 용어사전에 적은 등록과는 다른 용어라서 따로 정의하는게 맞겠네요.
감사합니다~
위에 적은 요구 사항에 없는 사항도 정의가 필요할까는 여전히 궁금해서 혹시 어떻게 생각하시는지 궁금합니다.

[wlroh]

아니면 WAITING을 주문이 등록된 상태라고 보면 될까요?

아! 이부분을 의도로 말씀드렸어요!

요구사항을 다시 확인해보니 ,

접수 대기 중인 주문만 접수할 수 있다.

해당 내용으로 되어 있엇네요. 접수 대기 가 아닌 등록된 상태 로 표현해서 오해가 생긴것 같네요 ㅎㅎ
접수 대기 라는 표현이 더 적절할 것 같아요

요구 사항에 없는 사항도 정의가 필요할까는 여전히 궁금해서 혹시 어떻게 생각하시는지 궁금합니다.

요구사항에 없는 사항이라는 것이 정확히는 요구사항의 워딩이라는 의미일까요?
아니면, 요구사항에 없는데 레거시코드에는 구현되어 있는 케이스일까요?

"요구사항에 없는 사항이라는 것이 정확히는 요구사항의 워딩이라는 의미일까요?" 의 의미였다면
요구사항에 있는 워딩을 꼭 그대로 활용할 필요는 없다고 생각해요.
용어를 도출하는 것 또한 결국 모델링 과정중에 하나라고 생각해요.
그렇다면 요구사항과 모델링은 무엇이 다를까 고민해보셔도 좋을 것 같아요.
요구사항과 모델링의 차이점때문에 저는 요구사항의 워딩을 그대로 활용하지 않아도 괜찮다고 생각해요 😄
고민해보시고 이부분에 대해서도 모델링 미션이 끝나면 같이 이야기해봐도 재밌을거같아요

[wlroh]

배달 라이더 는 공통에 있을 필요가 있을까 생각이 들어요.
주문 바운디드 컨텍스트로 옮겨보면 어떨까요?

[cjcjon]

배달 요구사항은 주문에 연관된 용어니까 주문으로 옮기는게 맞겠네요

[wlroh]

제가 봤을 때 메뉴 상품의 경우는 어떤 상품과 몇개의 수량으로 구성되었는지를 의미한다고 생각해요
어떻게 생각하시나요?

[cjcjon]

메뉴를 정의할 때 1개 이상의 상품으로 구성된 주문의 단위라고 정의했고,
메뉴 상품은 그에 따라서 특정 메뉴에 속한 상품들을 말한다라고 정의했었습니다.
그래서 메뉴:메뉴 상품 1:1로 통칭한다고 정의하려 했는데 코드도 그렇고 요구사항도 그렇고 이렇게 정의하면 올바르지 않겠네요.

위에서 메뉴가 메뉴 상품으로 구성된다고 정의를 바꾸었으니, 메뉴 상품은 어떤 걸로 구성되었는지 설명하는게 더 좋다고 생각해서 바꿀게요.

[wlroh]

준수님 안녕하세요 😄
피드백 잘 반영해주셨습니다 👍
질문에 대한 코멘트와 간단한 코멘트 작성했는데 확인부탁드려요!
궁금하신 내용이 있다면 편한 채널로 연락주세요

[wlroh]

주문 유형에는 어떤 것이 있는지 같이 정리하면 좋을 것 같아요
배달 주문, 포장 주문, 매장 주문에서 이미 주문 유형이라는 표현이 있지만, 한눈에 주문 유형에는 무엇이 있는 지 정리해주는게 더 빠르게 이해할 수 있을 것 같아요

[cjcjon]

같이 적어주는게 이해하기는 더 좋겠네요.
이런 유형의 설명이 enum 같은 것이라고 생각하는데요, 유형이 추가될 때마다 주문 유형 설명도 같이 수정해주지 않으면 언젠가는 누락될 것 같습니다(db의 type 같은 컬럼에 유형을 comment로 적어두는데, 서비스가 발전하다보면 항상 누락되더라고요).
아예 주문 유형이라는 새로운 타이틀을 빼고 그 곳에 용어들을 전부 빼두면 될 것 같은데 어떠세요?
유형을 이야기하신 것처럼 설명에 적어주지 않아도 읽는 사람이 이해하기 쉽고 신규로 주문 유형이 추가되어도 누락되지 않을 것 같아요.

[wlroh]

DM 으로 이야기했던 부분이여서 머지할게요!

[wlroh]

아니면 WAITING을 주문이 등록된 상태라고 보면 될까요?

아! 이부분을 의도로 말씀드렸어요!

요구사항을 다시 확인해보니 ,

접수 대기 중인 주문만 접수할 수 있다.

해당 내용으로 되어 있엇네요. 접수 대기 가 아닌 등록된 상태 로 표현해서 오해가 생긴것 같네요 ㅎㅎ
접수 대기 라는 표현이 더 적절할 것 같아요

요구 사항에 없는 사항도 정의가 필요할까는 여전히 궁금해서 혹시 어떻게 생각하시는지 궁금합니다.

요구사항에 없는 사항이라는 것이 정확히는 요구사항의 워딩이라는 의미일까요?
아니면, 요구사항에 없는데 레거시코드에는 구현되어 있는 케이스일까요?

"요구사항에 없는 사항이라는 것이 정확히는 요구사항의 워딩이라는 의미일까요?" 의 의미였다면
요구사항에 있는 워딩을 꼭 그대로 활용할 필요는 없다고 생각해요.
용어를 도출하는 것 또한 결국 모델링 과정중에 하나라고 생각해요.
그렇다면 요구사항과 모델링은 무엇이 다를까 고민해보셔도 좋을 것 같아요.
요구사항과 모델링의 차이점때문에 저는 요구사항의 워딩을 그대로 활용하지 않아도 괜찮다고 생각해요 😄
고민해보시고 이부분에 대해서도 모델링 미션이 끝나면 같이 이야기해봐도 재밌을거같아요

[wlroh]

준수님 안녕하세요 😄
피드백 잘 반영해주셨습니다 👍
용어사전은 한번에 끝나는 것이 아닌 모델링하면서도 꾸준한 업데이트가 필요하기에 이부분도 같이 참고해서 진행해보시면 좋을 것 같아요
그럼 다음 단계도 화이팅입니다 🔥