🧐 Today I Learned (TIL)
- 도메인 주도 설계
- 이벤트 스토밍
1. 도메인 주도 설계
우리가 흔히 아는 업무는 크게 4개(기획, 마케팅, 개발, 디자이너)로 나뉜다. 그리고 각 업무들이 맡은 임무를 수행할 때 '시장 조사 > 서비스 기획 > 베타 서비스 개발 > 마케팅(소규모/피드백) > 수정 기획 > 서비스 개발 > 마케팅' 순으로 진행을 한다.
이 과정속에서 각 업무를 수행하는 인원들간의 관점이 다르기 때문에 수 많은 갈등과 의사소통에 문제가 생긴다. 도메인(기획)과 그것을 추상화한 모델(개발자가 구현하기 위한 간단한 설계도)을 설계하고 개발을 하더라도 기획과 개발의 불일치가 발생하기 때문이다.
PM이 각 업무들의 사이에서 조율을 하는 중재자 역할을 수행한지만 바라보는 관점이 모두 다르고 서비스의 복잡도가 높기 때문에 모든 문제를 해결할 수는 없다.
기획과 개발의 불일치를 프로젝트에 참여하는 모든 인원들이 이해할 수 있는 공통적인 언어를 사용하고 하나의 모델만을 보고 해결하는 방안으로 도메인 주도 설계가 등장했다.
1-1. 전략적 설계
서비스에 일어날 수 있는 모든 상황(Context, 이벤트 스토밍)을 공유하고 공유된 모든 상황들을 그룹화(Bounded context)하고 그 관계를 정의하는 설계법이다.
1-2. 전술적 설계
그룹화된 상황(Bounded context)들을 더 세세하게 모델링을 하는 설계법이다. 계층형 아키텍처를 통해 도메인 모델을 분리하고 명확히 모델링하는 설계 방법이다. 쉽게 생각하면 전략적 설계의 상세한 부분을 설계하는 과정이라고 생각하면 된다.
2. 이벤트 스토밍
일반적으로 포스트잇으로 정의를 많이 하는 편이다.
2-1. 도메인 이벤트 정의
더 이상 생각이 안날 정도로 각자 생각나는 모든 이벤트를 보편 언어로 정리하고 서로 상이하면서 중복된 상황을 제거하거나 취합한다. 그리고 이벤트가 발생하는 시간 순서대로 정리하고 동시에 수행되는 이벤트는 수직으로 포스트잇을 정리한다.
2-2. 프로세스 그룹핑
동일한 비즈니스 주제로 이벤트를 그룹핑하는 단계로 보라색 포스트잇에 프로세스명과 간략한 설명 기술을 해준다. 비즈니스적으로 중요한 핵심 프로세스에 집중을 해야하고 중요한 이벤트가 누락되지 않았는지 검토한다. (너무 자세하게 이벤트를 식별하지 않음)
2-3. Command 정의
사용자의 행위가 Command되는 단계로 'CRUD'를 기반으로 '무엇을 OO한다'의 형태로 정의한다. 각 이벤트별로 발생시키는 Command를 생각하여 왼쪽에 붙인다. Command 하나에 1개 이상의 이벤트가 발생할 수 있다.
2-4. 트리거 정의 (행위자를 정의)
행위자를 정의하는 단계로 왼쪽하단에 겹쳐서 붙인다. 이벤트 발생과 관련된 외부 시스템(결제 시스템)이 있을 경우 이벤트 우측 상단에 겹쳐서 붙인다.
2-5. Aggregate 정의
Command 수행을 위해 'CRUD'해야 하는 데이터 객체를 정의한다. 각 이벤트를 발생시키기 위해 어떤 데이터가 필요한지 Command와 이벤트 사이의 위에 붙인다.
2-6. Bounded Context 정의
2-7. Context Map
각 Bounded Context간의 관계를 도식화한다.
📚 참고
