1. 이벤트 스토밍
1.1. 정의
•
사람들이 모여서 비즈니스 프로세스에 관해 브레인 스토밍하고 신속하게 모델링하기 위한 로우테크 활동
•
비즈니스 도메인 지식 공유를 위한 전술적 도구
1.2. 과정
1.
도메인 이벤트 검토
•
도메인 이벤트 브레인 스토밍
•
도메인 이벤트 타임 라인 정리
•
(Optional) 고충점, 중요 이벤트 식별
2.
모델링 세션
•
커맨드 및 액터 식별
•
정책 및 규칙 도출
•
(Optional) 읽기 모델 / 외부 시스템 및 API 식별
•
애그리거트 및 바운디드 컨텍스트 정의
1.2.1. 도메인 이벤트 브레인 스토밍
•
브레인 스토밍 대상
◦
비즈니스 도메인 관련된 도메인 이벤트
◦
비즈니스 도메인에서 발생 할 수 있는 모든 것
◦
도메인 전문가가 관심있는 어떤 사건
•
특징
◦
이벤트가 발생했다는 것은 상태가 변경되었다는 것을 의미
◦
데이터 구조가 아닌 비즈니스 프로세스를 최우선적으로 고려
•
진행 방식
◦
새로운 이벤트를 추가하는 속도가 현저히 느려질때 까지 진행
◦
토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록
▪
포스트잇을 붙이지 전에 합의 도달하여 논의하지 말것
◦
오랜지 색 포스트 잇으로 표현
▪
도메인 이벤트는 이미 발생한 일을 설명하므로 과거형으로 작성
예) 주문이 생성됐다 / 알림을 보냈다 / 비행기 요금이 예약됐다
1.2.2. 도메인 이벤트 타임 라인 정리
•
도메인 이벤트를 발생 순서대로 타임라인 배치
•
정상 시나리오(성공적인 비즈니스 시나리오)로 부터 시작
•
잘못된 이벤트 수정 / 중복 제거 / 누락된 이벤트 추가
•
목적
◦
이벤트 간의 관계와 의존성을 파악하고, 시스템의 흐름을 이해하는 데 도움
1.2.3. (Optional) 고충점(핫스팟)
•
주목할만한 포인트 식별
◦
예) 병목 구간, 자동화가 필요한 수작업 단계, 도메인 지식이 누락된 부분
•
참가자들의 주요 이슈나 관심사, 기존/신규 비즈니스 프로세스의 문제점
•
다이아몬드의 핑크색 포스트잇으로 표현
◦
왜 그것이 문제점인지 설명하는 문장 표시
1.2.4. (Optional) 중요 이벤트
•
중요 이벤트 (pivot event)
◦
컨텍스트나 국면이 바뀌는 것을 나타내는 중요한 비즈니스 이벤트
◦
예) 주문 과정에서 발생하는 중요한 상황 변화
▪
쇼핑 카트가 초기화 됐다 / 주문이 생성됐다 / 주문이 발송됐다
▪
주문이 배달됐다 / 주문이 반품됐다
•
중요 이벤트 전/후로 세로로 선을 그음
•
중요 이벤트 → 바운디드 컨텍스트의 후보
1.2.5. 커맨드 및 액터 식별
•
커멘드 (명령)
◦
이벤트를 발생 시키는 것 (도메인 이벤트가 발생하는 원인)
◦
무엇이 이벤트 또는 이벤트의 흐름을 시작하게 하는지 설명
▪
cf) 이벤트 - 이미 발생한 것을 설명
◦
(밝은) 파란색 포스트잇으로 작성
▪
시스템 오퍼레이션을 설명, 명령형으로 작성
•
예) 캠페인을 게시한다, 주문을 제출한다
▪
커맨드가 생성하는 이벤트 앞에 붙임
•
액터
◦
커맨드를 실행하는 비즈니스 도메인 내 사용자
◦
노란색 포스트잇으로 표현
◦
모든 커맨드가 액터와 연관되는 것은 아님
•
목적
◦
시스템의 사용자와 해당 사용자가 수행하는 작업을 명확하게 파악
1.2.6. 정책 및 규칙 도출
•
시스템의 비즈니스 규칙과 제약 조건을 나타내는 정책 및 규칙을 도출
•
자동화 정책(automation policy)
◦
이벤트가 커맨드의 실행을 시작하는 시나리오
◦
특정 도메인 이벤트가 발생할때 자동으로 실행
◦
커맨드에 관련된 액터가 없는 경우, 커맨드를 실행할 수 있게 해줌
•
보라색 포스트잇으로 표현
◦
이벤트와 커맨드 사이를 연결
•
예)
◦
이벤트 - 불만이 접수됐다
◦
커맨드 - 상부보고
◦
정책 - VIP 고객에 한함
•
목적
◦
시스템의 구조와 동작에 영향을 미치는 요소들을 명확하게 파악
1.2.7. (Optional) 읽기 모델 (리드 모델)
•
액터가 커맨드를 실행하는 의사결정을 내릴때 사용하는 시각적 데이터
•
액터의 의사결정을 돕는 필요한 정보의 원천
•
녹색 포스트잇으로 표현
1.2.8. (Optional) 외부 시스템 및 API 식별
•
도메인에 포함되지 않는 시스템과 상호 작용하는 외부 시스템과 API를 식별
◦
외부 시스템
▪
시스템 외부에 존재하는 다른 시스템
◦
API
▪
두 시스템 간의 통신을 위한 인터페이스
•
목적
◦
시스템의 외부 환경과의 상호 작용 방식을 이해하는 데 도움
•
예) 알림톡, 아임포트, 토스페이먼트
•
핑크색 포스트잇으로 표현
1.2.9. 애그리거트 및 바운디드 컨텍스트 정의
•
모든 이벤트와 커맨드가 표현되면 애그리거트 개념을 포함하여 모델 구성
◦
커맨드를 받고 이벤트를 생성
◦
서로 연관된 애그리거트를 찾아 연관을 지음
•
애그리게이트
◦
관련된 도메인 개념들을 하나의 그룹으로 묶은 개념
•
바운디드 컨텍스트
◦
명확한 경계를 가진 시스템 영역.
2. 컨텍스트 맵핑
2.1. 협력형 패턴 그룹
•
소통이 잘되는 팀에서 구현된 바운디드 컨텍스트
•
보통 단일 팀에 의해 구현된 바운디드 컨텍스트
2.1.1. 파트너십 패턴
•
각 팀이 하나의 바운디드 컨텍스트를 책임
•
바운디드 컨텍스트 간의 연동을 ad-hoc 방식으로 조정
◦
한 팀이 다른 팀에게 API 변경을 알림
◦
다른 팀은 충돌 없이 이를 받아 드림
•
잘 구축된 협업 실무, 높은 수준의 헌신, 팀간 잦은 동기화 필수
•
변경사항의 지속적인 통합 필요
2.1.2. 공유 커널 패턴
•
여러 바운디드 컨텍스트에서 구현되는 공유 모델
•
소스코드의 변경이 모든 바운디드 컨텍스트에 즉시 반영되도록 구현
•
공유하는 모델의 코드, 빌드 관리 및 테스트를 한팀에서 맡아서 수행
•
해당 패턴 결정 기준
◦
중복 비용과 조율 비용의 비율이 가장 중요
◦
바운디드 컨텍스트간의 강한 의존관계를 만듬
◦
중복 비용 > 조율 비용 → 해당 패턴 적용
•
단일 팀 원칙 위배 → 명분 필요
2.2. 사용자-제공자(customer - supplier) 패턴 그룹
•
서비스 제공자 (upstream)
•
고객 또는 사용자 (downstream)
•
연동 컨트랙트를 주도하는 권력의 불균형 존재
◦
순응주의자
◦
충돌 방지 계층
◦
오픈 호스트 서비스
2.2.1. 순응주의자 패턴 (Conformist)
•
힘의 균형이 서비스 제공자(업스트림 팀)에 있음
•
사용자의 선택지
◦
받아들이거나 떠나거나
•
예) 아마존과 제휴하는 판매자
2.2.2. 충돌 방지 계층 패턴 (ACL: anticorruption layer)
•
순응주의자 패턴에서 다운스트림 바운디드 컨텍스트가 이를 순응하지 않는 경우 사용
•
제공자의 모델을 따르는 것을 원치 않거나 순응에 필요한 노력이 가치가 없을때 사용
◦
다운 스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함하는 경우
◦
업스트림 모델이 사용자 요건에 비효율적이거나 불편한 경우
◦
제공자가 컨트랙트를 자주 변경하는 경우
•
특징
◦
충돌 방지 계층을 통해 업스트림 바운디드 컨텍스트를 가공
◦
가장 방어적인 컨텍스트 맵핑 관계
◦
통합에 용이한 모델 개념을 만듦
◦
외부의 개념으로부터 독립성 유지 가능
2.2.3. 오픈 호스트 서비스 패턴 (OHS: open-host service)
•
힘이 사용자 측에 있는 경우 사용
•
연동 모델(퍼블릭 인터페이스)와 구현 모델 분리
◦
구현 모델의 변경으로 부터 사용자를 보호
◦
다운스트림 바운디드 컨텍스트에 영향을 주지 않으면서 구현 자유롭게 발전 가능
•
공표된 언어 (published language)
◦
연동 지향 언어를 통해 사용자에게 편리한 프로토콜 노출
◦
JSON 스키마, Protobuf, Avro
◦
두 유비쿼터스 랭귀지 사이의 번역 제공
2.3. 분리형 노선 (separated ways)
•
팀에 협업 의지가 없거나 협업 할 수 없을 때 사용
•
커뮤니케이션 이슈
◦
커뮤니케이션 비용이 높고 협업이 어려운 경우, 컨텍스트 기능 중복 구현
•
일반 하위 도메인
◦
일반 하위 도메인이 일반 솔루션과 연동하기 쉬운 경우 사용
◦
로깅 프레임워크