event-storming-explorer 스킬

Big Picture Event Storming을 수행해 도메인 전반의 과거형 이벤트 타임라인과 액터를 뽑고, 이벤트 클러스터에서 서브도메인 후보를 식별한다.

Alberto Brandolini의 Event Storming 정통 방법을 스킬화한 것. 정책·커맨드·시스템 이름은 이 단계에서 다루지 않는다 (후속 단계의 Design-Level ES 몫).

이 스킬의 산출물은 2개:

• event-flow.md — 이벤트 타임라인 + 액터 + 핫스팟
• subdomain-map.md — 서브도메인 후보 (분류 전 상태, Core/Supporting/Generic 컬럼은 비어 있음)

분류는 다음 스킬 subdomain-classifier에서 같은 파일을 이어서 채운다.

---

대화 UX 규약 (필수)

• 카테고리 선택은 숫자 메뉴. 자유 입력 금지.
• 1문 1답 기본. 단순 Yes/No만 2~3개까지 번호 달아 묶기 허용.
• 진행 표시: [Q 3/12 · 근거: ...]
• "나중에" / "모름" / "스킵" 항상 허용 → ⚠️ 미정으로 산출물에 기록.
• 자가 진단·평가는 ✅/⚠️/❌ 3단계. 숫자 점수 금지.
• 이벤트는 반드시 과거형 — 한국어 "~됨/~함" / 영어 "PastParticiple". 정책·시스템 이름 금지.

---

1. 언제 트리거하는가

• /ddd-workshop:event-storming-explorer
• requirements-refiner 출력 직후
• "이벤트 스토밍", "빅픽처", "서브도메인 후보 찾아줘"
• 기존 event-flow.md 업데이트 → --update

---

2. 입력

• docs/requirements.md — 주 입력
  • 도메인 브리프, MUST/SHOULD 요구사항, 액터 목록, 맥락
  • UL 기본 언어 설정 (한국어 / 영어)

---

3. Step 0 — Upstream 일관성 스캔

자동 점검:

1. requirements.md 존재 확인. 없으면 "먼저 requirements-refiner 실행하세요" 안내.
2. 맥락(학습/개인/사내/B2B/B2C) 로드 → 세션 규모 조정.
3. UL 기본 언어 로드. 미지정이면 사용자에게 1회 질문.
4. 도메인 브리프에서 액터 후보와 주요 활동 동사 미리 뽑아 질문 시드로 보관.

결과 공개:

📋 Upstream 스캔
- 맥락: 사내 HR 플랫폼
- UL 기본 언어: 한국어
- 액터 후보: 사원, 관리자, 결재자
- 활동 동사 후보: 신청, 승인, 반려, 조정, 소멸
- ⚠️ 미정: 자동 부여 주기 근거법 조항 (requirements.md)

진행할까요? (1) 진행 2) 미정 해소 후 진행 3) 요구사항 수정으로 복귀)

---

4. 진행 단계

Step 1 — 주요 액터 확정

[Q · 액터 식별]

이 도메인의 주요 액터를 확정합니다. requirements에서 뽑은 후보:

1) 사원 (휴가 신청·조회)
2) 결재자 (승인·반려)
3) 관리자 (잔고 조정, 권한 관리)
4) 시스템 (자동 부여, 만료 처리)
5) 기타 추가

(복수 선택 가능, 예: 1,2,3)

시스템 액터도 포함. 자동 적립·만료·알림 발송 등은 시스템이 주체.

Step 2 — 이벤트 추출 (과거형 강제)

각 액터별로 "이 액터의 활동으로 시스템에 일어난 사건"을 과거형 동사로 수집:

[Q · 액터: 사원]

이 액터가 관여해서 시스템에 일어난 사건들은?

예시 포맷:
- 사원_초대됨 / EmployeeInvited
- 연차_신청됨 / LeaveRequested
- 연차_취소됨 / LeaveRequestCancelled

주의:
- 현재형·미래형 금지 ("신청한다" ❌ → "신청됨" ✅)
- 정책 아님 ("3일 이상은 특별승인" ❌)
- 커맨드 아님 ("연차 신청 제출" ❌ → "연차가 제출됨" ✅)
- 시스템 이름 아님 ("카프카에 발행됨" ❌)

자유 기술 후 1문 1답으로 다듬는다.

수집 후 확인: "이 이벤트가 진짜 도메인 사건이 맞는가, 아니면 기술적 처리인가?"

• "DB에 저장됨" ❌ (기술 레이어)
• "연차가 차감됨" ✅ (도메인 사건)

Step 3 — 이벤트 타임라인 배치

수집된 이벤트를 시간순으로 배치. 병렬·분기는 괄호로 표기.

[Q · 타임라인 배치]

다음 이벤트들을 시간순으로 배치했습니다. 맞나요?

1. 사원_초대됨
2. 사원_활성화됨
3. 연차잔고_초기화됨
4. 연차_적립됨 (매월)
5. 연차_신청됨
6. 신청이_제출됨
7. (분기)
   6a. 신청이_승인됨 → 연차가_차감됨
   6b. 신청이_반려됨
8. 연차_소멸됨 (1년 경과)

1) 맞음
2) 순서 수정
3) 누락된 이벤트 추가
4) 이벤트 제거

Step 4 — 핫스팟(Hotspot) 식별

핫스팟 = 모순·미정·논란 지점. 빨간 스티커에 해당.

[Q · 핫스팟 식별]

이 흐름에서 미정이거나 모순된 지점이 있나요?

체크 항목:
- 예외 흐름이 명확하지 않은 곳
- 이해관계자 간 의견이 달랐던 곳
- 자동·수동 경계가 모호한 곳
- 법·규제 요건이 불명확한 곳

예: ⚠️ "퇴사 시 진행 중 신청을 자동 취소? 수동? 미정"

Step 5 — 서브도메인 후보 클러스터링

타임라인의 이벤트를 언어·리듬·액터·관심사로 묶어 서브도메인 후보를 제안.

[Q · 서브도메인 후보]

이벤트를 다음과 같이 묶어봤습니다. 동의하시나요?

A. 조직 관리
   - 사원_초대됨, 사원_활성화됨, 사원_퇴사됨, 부서_생성됨

B. 연차 잔고 회계
   - 연차잔고_초기화됨, 연차_적립됨, 연차_차감됨, 연차_소멸됨

C. 연차 신청·결재
   - 연차_신청됨, 신청이_제출됨, 신청이_승인됨, 신청이_반려됨

D. 알림
   - 이메일_발송됨, 웹푸시_발송됨

1) 이대로 OK
2) 클러스터 병합/분리
3) 이벤트를 다른 클러스터로 이동
4) 서브도메인 이름 변경

주의: 이 단계에서는 분류(Core/Supporting/Generic) 금지. 그건 다음 스킬의 일. 지금은 "무엇이 있나"만.

Step 6 — 동음이의어·미정 항목 정리

• 같은 단어가 서로 다른 맥락에서 다른 의미로 쓰이면 표시 → 후속 BC 설계의 경계 단서.
• 핫스팟·미정 항목을 ⚠️ 로 마킹.

---

5. 산출물

5.1 docs/shared/event-flow.md

기본 경로 docs/shared/event-flow.md. 프로젝트 관례가 다르면 사용자에게 확인.

Frontmatter 없음. 본문만.

# Event Flow (Big Picture)

## 전제
- 시점: 전역 시간축
- 포함: 과거형 도메인 이벤트, 액터
- 제외: 정책(Policy), 커맨드, 시스템 이름, 분기 로직
- UL 기본 언어: 한국어 (Code Identifier는 영어 병기)

## 액터
- **사원**: 연차 신청·조회
- **결재자**: 승인·반려
- **관리자**: 잔고 조정, 권한 관리
- **시스템**: 자동 부여·만료, 알림 발송

## 이벤트 타임라인

### 1. 사원 생애주기
- 사원이 초대됨 (EmployeeInvited)
- 사원이 활성화됨 (EmployeeActivated)
- 연차잔고가 초기화됨 (LeaveBalanceInitialized)
- ...
- 사원이 퇴사함 (EmployeeTerminated)

### 2. 연차 부여·소멸
- 연차가 적립됨 (LeaveBalanceAccrued) — 매월
- 연차가 소멸됨 (LeaveBalanceExpired) — 부여 후 1년

### 3. 연차 신청·승인
- [사원] 연차 신청을 작성함
  → 신청이 임시저장됨 (LeaveRequestDrafted)
  → 신청이 제출됨 (LeaveRequestSubmitted)
- [결재자]
  → 신청이 승인됨 (LeaveRequestApproved)
    → 연차가 차감됨 (LeaveBalanceConsumed)
  → 또는 신청이 반려됨 (LeaveRequestRejected)
- [사원]
  → 신청이 취소됨 (LeaveRequestCancelled)
    → 연차가 복원됨 (LeaveBalanceRestored)

## 핫스팟 (⚠️ 미정·모순)

- ⚠️ 퇴사 시 진행 중 신청 자동 취소 여부
- ⚠️ 만료 경계에서 취소된 신청의 복원 처리
- ⚠️ 자동 부여 주기의 근거 법조항 (근기법 60조?)

## 동음이의어 후보
- "연차" — 잔고 개념 vs 휴가 종류 (종일/반차) 구분 필요
- "취소" — 신청 단계 vs 승인 후 단계 구분 필요

5.2 docs/shared/subdomain-map.md (분류 전)

# Subdomain Map

> 이 문서는 2단계(event-storming-explorer)에서 **후보 식별**까지 작성됨.
> 3단계(subdomain-classifier)에서 Core/Supporting/Generic **분류** 컬럼이 채워짐.

## 서브도메인 후보

| # | 서브도메인 | 포함 이벤트 | 분류 | Why |
|---|---|---|---|---|
| A | 조직 관리 | 사원 생애주기, 부서, 직위 | _미정_ | _미정_ |
| B | 연차 잔고 회계 | 적립·차감·소멸·조정 | _미정_ | _미정_ |
| C | 연차 신청·결재 | 신청·제출·승인·반려·취소 | _미정_ | _미정_ |
| D | 알림 | 이메일·웹푸시 발송 | _미정_ | _미정_ |

## 각 서브도메인 상세

### A. 조직 관리
- 관여 액터: 관리자, 시스템
- 핵심 언어: 사원, 부서, 직위, 직책, 초대, 활성화, 퇴사
- 경계 근거: 사원 생애주기 이벤트 군집

### B. 연차 잔고 회계
- 관여 액터: 사원, 관리자, 시스템
- 핵심 언어: 연차(잔고), 적립, 차감, 복원, 조정, 소멸, 원장
- 경계 근거: 회계성 이벤트(append-only) 군집

### C. 연차 신청·결재
...

## 다음 단계

→ `subdomain-classifier` 실행.
- 각 서브도메인에 Core/Supporting/Generic 분류 + Why 작성
- Slice-first 대상 Core 선정

---

6. 업데이트 모드 (--update)

1. requirements.md updated_at 비교 → stale 경고.
2. "무엇을 업데이트?" 숫자 메뉴:

   1) 액터 추가/제거
   2) 이벤트 추가/제거/순서 수정
   3) 핫스팟 추가/해소
   4) 서브도메인 클러스터 재편
   

3. 해당 부분만 delta 질문.

주의: subdomain-map.md의 분류 컬럼이 이미 채워져 있으면 subdomain-classifier에 영향 → 경고 후 진행.

---

7. 강제 체크리스트

□ Step 0 upstream 스캔 완료
□ 액터 목록 확정 (시스템 액터 포함)
□ 모든 이벤트 과거형
□ 기술 레이어 이벤트 제외 (DB·Kafka 등)
□ 정책·커맨드·시스템 이름 없음
□ 타임라인 시간순 배치
□ 핫스팟 식별 (없으면 "없음" 명시)
□ 서브도메인 후보 3~7개
□ subdomain-map.md 분류 컬럼은 비어 있음 (_미정_)
□ Frontmatter 없음

---

8. 맥락별 조정

맥락	이벤트 수	클러스터 수	깊이
학습	5~10	1~2	얕음
개인	10~20	2~3	중간
사내	15~40	3~5	중간
B2B	20~60	4~7	깊음
B2C	30~80	4~7	깊음

---

9. 절대 하지 말 것

• 이벤트에 정책·커맨드·시스템 이름 섞기 ("Kafka에 발행됨" ❌).
• 현재형·미래형 이벤트 ("신청한다" ❌).
• 서브도메인을 Core/Supporting/Generic으로 분류하기 (다음 스킬 몫).
• BC(Bounded Context)로 바로 넘어가기 (4단계 context-designer 몫).
• 기술 스택 이름 언급 (Spring·Kafka·Redis 등).
• 타임라인 없이 이벤트 목록만 나열.
• Frontmatter 추가.

---

10. 왜 이 순서인가

Evans/Vernon 정통 전략적 설계 순서:

Domain → Subdomain 식별 → UL → Bounded Context → Context Map

이 스킬은 Subdomain 식별을 담당한다. Big Picture Event Storming은 이벤트 클러스터로 서브도메인 경계의 1차 증거를 만든다.

분류(Core/Supporting/Generic)를 같이 하지 않는 이유:

• 식별은 기술적·현상적 사고 (도메인 전문가와).
• 분류는 전략적·투자 판단 (비즈니스 결정자와).
• 섞으면 "Core가 될 만한 것"을 먼저 찾는 편향이 생겨 식별이 왜곡.
• 전체 목록을 보고 분류하는 게 상대적 비교 품질 ↑.