학습배경
모모플젝이 점점 커지면서 설계에 대한 고민이 생겼다. 이전의 플젝은 단순한 CRUD게시판이 전부라 설계라는게 없이 바로 제작을 했다. ERD조차 먼저 짜지 않고.
그러나 기획자님의 요구사항이 늘어나면서 관리자와 유저가 분리가 되었고 기능이 복잡해지면서 어떻게 설계할것인지 고민하게 되었다.
그렇게 찾게 된 것이 이벤트 스토밍이다.
기능이 엄청 늘어났다 ㅎㅎ
이벤트 스토밍이란
이벤트스토밍은 Event와 BrainStorming의 합성어로 Domain Expert와 개발 전문가가 함께 모여 워크샵 형태로 진행되는 방법론이다. 협업을 하게되면 비개발자와 개발자로 나눠지고 개발자도 프론트 백엔드로 나뉘어 각자의 용어가 충돌하게 된다. 같은 회원가입-로그인이라는 과정이라고 해도 각자가 알고있는 과정은 천차만별이다. 이런 이해의 차이를 없애고 서로가 같은 목표와 프로세스를 가지고 프로젝트를 할 수 있도록 도와주는 과정이 이벤트 스토밍이다.
진행 방법
사실 이벤트 스토밍은 사회자의 역할이 중요하다. 이벤트 스토밍 자체가 모두의 의견을 수렴하고 조율하면서 토의하는 과정이다보니 그만큼 지식을 폭넓게 알고있어야 한다. 하물며 도중에 산으로 가지 않도록 모든 조원들을 이끌 수 있어야 한다. 이는 커뮤니케이션도 중요하며 지식도 많아야 한다는 것이다.
하지만 모두가 배우는 단계이기에 다른 포지션까지 포함 하기엔 실력이 부족하다고 판단되었다. 백엔드 개발자끼리 먼저 진행해보기로 했다.
작업 툴 - 피그마
피그마라는 사이트를 이용하면 직접 만나서 포스트잇을 붙일 필요 없이
모두가 온라인에서 진행이 가능하다.
포스트잇의 의미
| 유형 | 색깔 | 설명 |
|---|---|---|
| 도메인 이벤트 | 오렌지색 | 발생된 사건, 과거시제 동사로 표현 |
| 커맨드 | 파란색 | 이벤트를 트리거하는 명령 |
| 외부 시스템 | 핑크색 | 이벤트가 호출하거나 관계가 있는 레거시 또는 외부 시스템, 장비 |
| 액터 | 노란색 작은 포스트잇 | 개인 또는 조직의 역할 |
| 어그리게잇 | 노란색 큰 포스트잇 | 상태가 변경되는 데이터 |
| 정책 | 라일락 색 | 이벤트 조건에 따라 진행되는 결정 When [이벤트]then [커맨드] |
| 핫스팟 | 보라 색 | 의문, 질문, 미결정 사항 |
진행과정
- 팀원 모두가 각자 영역에서 서비스의 흐름을 주황색 포스트잇에 적어 나열한다.
단, 각각의 서비스는 모두 과거 시제여야만 한다. (ex 회원가입을 했다.) - 20~30여분 시간동안 각자 진행한 뒤 팀원 모두가 모여 각자의 서비스 흐름을 설명한다. 여기서 동일한 내용은 하나로 정리하며 토의한다.
- 주황생 포스트잇이 모두 정리되어 하나의 서비스 흐름이 완성되었다면 여기 각각의 파란색 포스트잇에 동사를 적는다. (ex 회원가입을 했다 -> 회원가입)
백엔드에서는 이게 메소드 이름이 된다! 영어로 번역하게 되겠지만 ㅎㅎ - 서비스 흐름을 만들다보면 외부시스템이 도출된다. 예를들어 Oauth 로그인, 혹은 결제와 같이 본 서비스가 아닌 부차적인(외부)서비스를 핑크색으로 적는다.
- 액터는 역할자이다. 해당 기능을 수행하는 구체적인 역할자를 넣어 도출한다. 여기에는 관리자, 구매자, 배송자등으로 구체화 될 수 있다. 권한을 확인하는 용도!
- 핫스팟은 결정하기 힘든사항, 혹은 의문점이다.
- 어그리게잇은 DDD의 요소중 가장 작은 도메인 모델의 모듈 단위이다.
앞서 만든 주황색(과거시제) + 파란색(메소드형 동사)를 함축적으로 쓸수 있는 명사를 만든다. 이것은 커맨드와 이벤트가 영향을 주는 데이터 요소이다.
예를들어 상품 "카탈로그 조회됨" + "상품 카탈로그 조회"의 포스트잇이 있다면 "상품 카탈로그"라는 명사형으로 이 작은 서비스의 도메인이 된다. - 비슷한 기능끼리 묶어 분리한다. 이것들이 메인 도메인이다.
- 연관관계를 정리하여 기능 명세를 만든다.
따라해보기!
진행하면서 생긴 에러사항
- 기능 관점으로 할것이냐 액터 관점으로 할것이냐 고민을 하게되었다
모두가 처음이다보니 기능부터 시작하기에는 난이도가 높다고 판단.
관리자와 유저의 관점(액터)관점을 위주로 작업을 시작하였다.
- 액터 관점으로 간단한 회원가입-로그인-로그아웃 과정만 진행해보기로함
- 유저끼리 통합 시작
비슷하면서도 다른 용어들이 충돌된다. 이때 어떤 의도로 적은것인지 이야기를 나누며 하나씩 통합시켜나가야 한다.
하나로 정리된 기능은 주황색 포스트잇으로 변경했다
- 메서드 정리, 보류할것들 정리
기획자님께서 주신 기능이나 모호한 부분을 분홍색 포스트잇에 따로 분류시켰다.
- 유저가 완료되었다. 관리자 시작!
여기까지 대략 1시간이 걸림
액터중심으로 하다보니 비슷한 기능이 많아서 뒤로갈수록 속도가 붙었다. 만약 유저와 관리자를 동시에 시작하는- 기능중심의 이벤트 스토밍을 하였다면 어디서부터 어떻게 해야할지 감잡기 어려웠을것 같다.
- 완료
진행후 느낀점
처음에는 이벤트 스토밍의 필요성을 느끼지 못했다. 이건 국어시간인가 아니면 토론시간인가. 굳이 해야해? 시간낭비 아니야? 라는 생각이 컸다. 하지만 같은 회원가입-로그인 기능이더라도 누구는 Oauth를 염두하기도 했으며 프론트입장에서 쓰는 용어, 서버입장에서 쓰는 용어가 제각기 달라 재미있었다. 최종적으로 하나의 서비스 로직이 완성되었을때 팀원 모두가 같은 방향성을 보고 무엇을 해야하는지 숙지할수 있었기에 뜻깊은 시간이 되었다고 생각한다.
다음 시간에는 도출된 서비스 로직에 대한 기능명세를 제작할 예정이다
참고자료
https://engineering-skcc.github.io/microservice%20modeling/Event-Storming/#fn:3
http://www.msaschool.io/operation/design/design-three/
https://rok93.tistory.com/170
