4. 유스 케이스 정리

유스 케이스 정리

헥사고날은 처음이라 유스 케이스를 더욱 신중하게 작성해야 했다. 진행 과정을 pseudo 코드로 작성했고 각 기능마다 검증 체크 리스트를 만들었다.

회원은 게시된 쿠폰을 발행한다.

1. 회원 정보를 조회한다.
2. 쿠폰정보를 조회한다.
3. 가게가 가진 게시된 쿠폰 북에서 쿠폰을 발행한다.
4. 발급된 쿠폰을 사용자의 쿠폰북에 추가한다.
5. 가게 단골 손님으로 등록한다.

검증 목록

• 회원은 가게에 게시된 쿠폰북에서 쿠폰을 꺼내 자신의 쿠폰 북에 담는다.
• 이미 가진 쿠폰이라면 발행 할 수 없다.(도메인과 중복 검증)
• 게시되지 않은 쿠폰은 발행 될 수 없다.(도메인과 중복 검증)

가게 주인은 쿠폰을 가게에 게시한다.

1. 가게 주인 정보를 조회한다.
2. 게시할 쿠폰을 생성한다.
3. 가게 주인은 가게에다 게시된 쿠폰북에 쿠폰을 게시한다.

검증 목록

• 가게 주인은 가게에 쿠폰을 게시할 수 있다.
• 게시된 쿠폰북에 동일한 쿠폰이 있을 수 없다.(도메인과 중복 검증)

가게 주인은 단골들에게 쿠폰을 뿌린다.

1. 가게 주인 정보를 조회한다.
2. 아직 나눠준적 없는 쿠폰이라면 쿠폰을 생성해 나눠준 쿠폰북에 쿠폰을 추가한다.
3. 단골들 중 동일한 쿠폰을 아직 받지 않은 사용자에게 쿠폰을 뿌린다.

검증 목록

• 가게 주인은 가게에 쿠폰을 뿌릴 수 있다.
• 이미 나눠줬던 쿠폰을 다시 나눠줄 때 새로운 단골들에게만 나눠준다.

회원은 쿠폰을 사용한다.

1. 회원 정보를 조회한다.
2. 쿠폰 정보를 조회한다.
3. 회원이 가진 쿠폰북에서 쿠폰을 사용한다.
4. 가게에서 사용한 쿠폰을 받는다.

검증 목록

• 회원은 가게에 쿠폰을 사용할 수 있다.
• 이미 사용한 쿠폰은 사용할 수 없다.(도메인과 중복 검증)
• 게시되지 않거나 나눠주지 않은 쿠폰은 사용할 수 없다.(도메인과 중복 검증)

마지막으로

사용자 시나리오를 기준으로 쿠폰 시스템을 만들다 보니 필요외 기능이 많이 만들어졌다. 분명 실무에도 워크 플로우를 도메인으로 분리했지만 어디에도 붙지 못하는 애매한 기능이 남아있게 되는데 딱 그런 상황이다. 도메인 주도 설계를 망치는 깨진 유리창 만들기가 되지 않도록 경계할 필요가 있다.

깨진 유리창인지 확인하는 방법은 간단하게 추가 기능에 유연하게 대응할 수 있을까이다. 만약 유연하게 대응하지 못하고 쿠폰 외 도메인 수정이 발생하면 깨진 유리창이라는 신호로 볼 수 있어보인다. 앞으로 상상 주도 개발을 통해 추가되는 기능을 유연하게 추가해보겠다.