1.3 이벤트 스토밍 워크샵 진행

이벤트 스토밍(Event Storming) 워크샵은 체계적인 단계별 접근을 통해 도메인에 대한 깊은 이해와 효과적인 모델링을 달성합니다. 이 장에서는 워크샵의 각 단계별 진행 방법과 주의사항을 상세히 설명합니다.

1. 도메인 이벤트 도출

도메인 이벤트 도출은 워크샵의 첫 단계로, 시스템에서 발생하는 모든 중요한 상태 변화를 식별하는 과정입니다. 이 단계에서는 참여자들의 자유로운 의견 개진을 통해 가능한 많은 이벤트를 발견하는 것이 중요합니다.

1.1 브레인스토밍 기본 원칙

브레인스토밍 과정에서는 다음과 같은 기본 원칙을 준수해야 합니다:

첫째, 모든 의견을 수용합니다. 이 단계에서는 어떠한 의견도 비판하지 않으며, 가능한 많은 이벤트를 도출하는 것에 집중합니다.

둘째, 신속하게 진행합니다. 각 참여자는 생각나는 이벤트를 즉시 작성하여 공유하며, 긴 토론은 피합니다.

셋째, 정해진 시간을 준수합니다. 일반적으로 이 단계는 60-90분 정도가 적절합니다.

1.2 이벤트 작성 가이드라인

효과적인 도메인 이벤트 작성을 위해 다음 가이드라인을 따릅니다:

모든 이벤트는 과거형으로 작성합니다. 예를 들어:

• “도서대출됨”
• “회원가입승인됨”
• “대출기한만료됨”

하나의 이벤트는 반드시 하나의 스티커에 작성합니다. 이는 나중에 이벤트를 재배치하거나 그룹화할 때 유용합니다.

각 이벤트는 업무적으로 의미 있는 상태 변화를 나타내야 합니다. 단순한 데이터 변경이나 기술적인 작업은 이벤트로 작성하지 않습니다.

1.3 주요 도메인 이벤트 예시

도서관 시스템의 주요 도메인 이벤트는 다음과 같은 카테고리로 구분할 수 있습니다:

회원 관련 이벤트는 회원의 상태 변화를 나타냅니다:

• 회원가입됨: 새로운 회원이 시스템에 등록되었음을 나타냅니다.
• 회원정보수정됨: 회원의 기본 정보가 변경되었음을 의미합니다.
• 회원등급변경됨: 회원의 서비스 이용 등급이 조정되었음을 나타냅니다.

도서 관련 이벤트는 도서 정보의 생명주기를 표현합니다:

• 도서등록됨: 새로운 도서가 시스템에 등록되었음을 나타냅니다.
• 도서정보수정됨: 도서의 메타데이터가 수정되었음을 의미합니다.
• 도서폐기됨: 더 이상 대출이 불가능한 상태로 변경되었음을 나타냅니다.

2. 커맨드와 액터 식별

커맨드(Command)와 액터(Actor) 식별은 도메인 이벤트의 발생 원인과 주체를 명확히 하는 단계입니다. 이 과정을 통해 시스템의 상호작용 패턴과 책임 구조를 이해할 수 있습니다.

2.1 액터별 주요 커맨드 분석

시스템의 주요 액터들은 각자의 역할과 책임에 따라 서로 다른 커맨드를 수행합니다. 도서관 시스템의 주요 액터와 그들의 커맨드를 살펴보겠습니다.

2.1.1 회원의 커맨드

회원은 도서관 서비스의 주요 사용자로서 다음과 같은 커맨드를 수행합니다:

도서 이용과 관련된 커맨드:

• 도서검색하기: 원하는 도서를 찾기 위해 다양한 조건으로 검색을 수행합니다.
• 도서대출신청하기: 이용 가능한 도서에 대해 대출을 요청합니다.
• 도서반납하기: 대출한 도서를 반납 처리합니다.
• 대출연장신청하기: 현재 대출 중인 도서의 반납 기한 연장을 요청합니다.

예약 관련 커맨드:

• 예약신청하기: 현재 대출 중인 도서에 대해 예약을 신청합니다.
• 예약취소하기: 기존에 신청한 예약을 취소합니다.

2.1.2 사서의 커맨드

사서는 도서관 운영의 관리자로서 다음과 같은 커맨드를 담당합니다:

도서 관리 커맨드:

• 도서등록하기: 새로운 도서를 시스템에 등록합니다.
• 도서정보수정하기: 기존 도서의 정보를 업데이트합니다.
• 도서폐기처리하기: 더 이상 이용할 수 없는 도서를 폐기 처리합니다.

회원 관리 커맨드:

• 회원등록승인하기: 신규 회원의 가입 신청을 검토하고 승인합니다.
• 회원자격정지처리하기: 규정 위반 회원의 이용 자격을 정지시킵니다.

2.1.3 시스템의 자동화된 커맨드

시스템은 다음과 같은 자동화된 커맨드를 실행합니다:

알림 관련 커맨드:

• 반납기한알림발송하기: 반납 기한이 임박한 회원에게 알림을 발송합니다.
• 예약도서도착알림발송하기: 예약한 도서가 반납되었을 때 회원에게 알립니다.

자동 처리 커맨드:

• 연체자동처리하기: 반납 기한이 지난 대출에 대해 연체 처리를 수행합니다.
• 예약만료처리하기: 기한 내 대출되지 않은 예약을 자동으로 취소합니다.

2.2 커맨드 상세 명세 작성

각 커맨드는 다음과 같은 요소들을 포함하여 상세히 명세해야 합니다:

선행 조건:

• 커맨드 실행을 위해 만족해야 하는 조건들을 명시합니다.
• 사용자의 권한이나 시스템의 상태 요구사항을 포함합니다.

후행 조건:

• 커맨드 실행 후 보장되어야 하는 결과를 정의합니다.
• 상태 변경이나 후속 이벤트 발생 여부를 명시합니다.

예를 들어, ‘도서대출신청하기’ 커맨드의 상세 명세는 다음과 같습니다:

선행 조건:

• 회원 자격이 유효한 상태여야 합니다.
• 연체 중인 상태가 아니어야 합니다.
• 대출 가능한 도서 수량에 여유가 있어야 합니다.
• 대상 도서가 대출 가능한 상태여야 합니다.

후행 조건:

• 도서의 상태가 ‘대출 중’으로 변경됩니다.
• 회원의 대출 현황이 업데이트됩니다.
• 대출 이력이 생성됩니다.
• 반납 예정일이 설정됩니다.

3. 애그리거트 도출

애그리거트(Aggregate) 도출은 이벤트 스토밍의 핵심 단계로, 도메인의 일관성 경계를 정의하고 객체들의 응집된 클러스터를 식별하는 과정입니다.

3.1 애그리거트 도출의 목적과 가치

애그리거트 도출은 다음과 같은 목적을 가집니다:

첫째, 트랜잭션 일관성의 경계를 설정합니다. 하나의 트랜잭션에서 함께 변경되어야 하는 객체들을 하나의 단위로 묶습니다.

둘째, 불변식(Invariants)을 효과적으로 관리합니다. 도메인의 핵심 규칙들이 항상 지켜질 수 있도록 보장하는 경계를 형성합니다.

셋째, 복잡성을 관리합니다. 연관된 객체들을 의미 있는 단위로 그룹화하여 시스템의 복잡성을 낮춥니다.

3.2 애그리거트 도출 프로세스

애그리거트를 효과적으로 도출하기 위해서는 체계적인 접근이 필요합니다. 이 과정은 도메인 이벤트와 커맨드를 기반으로 연관된 데이터와 행위를 식별하고 그룹화하는 작업입니다.

3.2.1 핵심 엔티티 식별

먼저 도메인의 핵심이 되는 엔티티들을 식별합니다. 도서관 시스템의 경우, 다음과 같은 핵심 엔티티들이 존재합니다.

도서(Book) 엔티티는 다음과 같은 속성을 가집니다:

• ISBN: 도서의 고유 식별자입니다.
• 제목: 도서의 이름입니다.
• 저자: 도서를 작성한 저자의 정보입니다.
• 출판사: 도서를 출판한 출판사의 정보입니다.
• 출판일: 도서가 출판된 날짜입니다.

이러한 정보는 도서의 메타데이터로서, 도서 자체의 정보를 나타냅니다. 실제 대출과 반납의 대상이 되는 것은 이 도서의 물리적인 복본입니다.

3.2.2 애그리거트 경계 설정

다음으로는 식별된 엔티티들 중에서 함께 관리되어야 하는 것들을 그룹화하여 애그리거트의 경계를 설정합니다. 이 때 다음과 같은 기준을 고려합니다.

업무 규칙의 일관성: 도서 복본(BookCopy) 애그리거트는 다음과 같은 규칙들을 하나의 단위로 관리합니다:

• 한 번에 한 명의 회원만 대출할 수 있습니다.
• 대출 기간은 기본 14일이며, 한 번의 연장이 가능합니다.
• 예약이 있는 도서는 예약자 외에 대출할 수 없습니다.

트랜잭션 단위: 회원(Member) 애그리거트는 다음과 같은 작업들을 하나의 트랜잭션으로 처리합니다:

• 회원 정보 변경 시 관련된 모든 데이터가 함께 업데이트되어야 합니다.
• 대출 한도 검사와 대출 처리가 원자적으로 수행되어야 합니다.
• 연체 상태 변경과 대출 제한이 동시에 적용되어야 합니다.

3.2.3 애그리거트 루트 선정

각 애그리거트에서 가장 중요한 엔티티를 루트로 선정합니다. 애그리거트 루트는 해당 애그리거트의 일관성을 책임지는 주체가 됩니다.

도서 복본 애그리거트의 경우: BookCopy 엔티티가 루트가 되어 다음과 같은 책임을 수행합니다:

• 대출 가능 여부 검사
• 대출 상태 변경 관리
• 예약 가능 여부 판단
• 도서 상태 이력 관리

회원 애그리거트의 경우: Member 엔티티가 루트가 되어 다음과 같은 책임을 수행합니다:

• 회원 자격 상태 관리
• 대출 한도 검사
• 연체 상태 관리
• 회원 이력 관리

3.3 주요 애그리거트 상세 명세

도서관 시스템의 주요 애그리거트들을 상세히 살펴보겠습니다. 각 애그리거트는 명확한 경계와 책임을 가지며, 도메인의 핵심 규칙들을 캡슐화합니다.

3.3.1 도서 복본 애그리거트

도서 복본 애그리거트는 실제 대출 가능한 도서의 물리적 복사본을 관리합니다.

구성 요소:

• BookCopy (애그리거트 루트): 개별 도서 복본을 나타냅니다.
• Checkout (엔티티): 대출 정보를 관리합니다.
• Location (값 객체): 도서의 물리적 위치 정보를 나타냅니다.
• BookStatus (값 객체): 도서의 현재 상태를 나타냅니다.

주요 불변식:

• 하나의 도서 복본은 동시에 한 명에게만 대출될 수 있습니다.
• 파손되거나 분실된 도서는 대출이 불가능합니다.
• 예약된 도서는 예약자에게만 대출이 가능합니다.

3.3.2 회원 애그리거트

회원 애그리거트는 도서관 이용자의 정보와 대출 관련 상태를 관리합니다.

구성 요소:

• Member (애그리거트 루트): 회원의 기본 정보를 관리합니다.
• MemberStatus (값 객체): 회원의 현재 상태를 나타냅니다.
• Address (값 객체): 회원의 주소 정보를 관리합니다.

주요 불변식:

• 회원은 최대 5권까지만 동시에 대출할 수 있습니다.
• 연체 중인 회원은 추가 대출이 불가능합니다.
• 회원 자격이 정지된 경우 모든 도서관 서비스 이용이 제한됩니다.

3.4 애그리거트 간 상호작용

애그리거트 간의 상호작용은 주로 식별자 참조와 이벤트를 통해 이루어집니다. 이는 애그리거트 간의 결합도를 낮추고 확장성을 높이는 중요한 설계 원칙입니다.

참조 관계의 예시:

• BookCopy는 Book의 ISBN을 참조하여 도서 정보를 식별합니다.
• Borrowing은 Member의 ID를 참조하여 대출자를 식별합니다.
• Reservation은 BookCopy와 Member의 ID를 참조하여 예약 정보를 관리합니다.

이벤트 기반 상호작용의 예시:

• 도서가 반납되면 ‘BookReturned’ 이벤트가 발생하고, 이를 구독하는 예약 시스템이 대기 중인 예약자에게 알림을 발송합니다.
• 회원의 연체 상태가 변경되면 ‘MemberOverdue’ 이벤트가 발생하고, 이는 대출 시스템의 제한 설정에 반영됩니다.

이러한 설계를 통해 각 애그리거트는 자신의 책임을 충실히 수행하면서도, 전체 시스템이 유기적으로 작동할 수 있게 됩니다.

1.3 이벤트 스토밍 워크샵 진행

[기존 내용 유지…]

4. 불변식의 발견과 정의

불변식(Invariants)은 시스템이 항상 지켜야 하는 핵심 규칙들입니다. 이 규칙들은 도메인의 일관성과 무결성을 보장하는 중요한 제약조건으로 작용합니다. 불변식의 발견과 정의는 이벤트 스토밍 전반에 걸쳐 점진적으로 이루어지는 과정입니다.

4.1 도메인 이벤트 단계에서의 불변식 발견

도메인 이벤트를 도출하는 과정에서 우리는 자연스럽게 첫 번째 단계의 불변식들을 발견하게 됩니다. 이는 각 이벤트의 발생 조건을 검토하면서 이루어집니다.

예를 들어, “도서대출됨” 이벤트를 논의할 때 다음과 같은 질문들이 제기됩니다:

• 한 회원이 동시에 몇 권까지 도서를 대출할 수 있는가?
• 어떤 경우에 도서 대출이 거부되어야 하는가?
• 도서가 대출 가능한 상태인지는 어떻게 판단하는가?

이러한 질문들을 통해 다음과 같은 기본적인 불변식들이 도출됩니다:

• 회원당 최대 대출 가능 도서 수는 5권입니다.
• 훼손되거나 분실된 도서는 대출할 수 없습니다.
• 이미 대출 중인 도서는 다시 대출할 수 없습니다.

4.2 커맨드 정의 단계에서의 불변식 구체화

커맨드를 정의하는 단계에서는 앞서 발견된 불변식들이 더욱 구체화되며, 새로운 불변식들도 추가로 발견됩니다. 각 커맨드의 실행 조건을 검토하면서 이루어지는 이 과정은 시스템의 동작 규칙을 더욱 명확히 합니다.

“도서대출신청하기” 커맨드를 예로 들어보겠습니다:

선행 조건 검토를 통한 불변식 발견:

• 연체 중인 회원은 새로운 도서를 대출할 수 없습니다.
• 회원 자격이 정지된 상태에서는 대출이 불가능합니다.
• 예약된 도서는 예약자에게만 대출이 허용됩니다.

후행 조건 검토를 통한 불변식 발견:

• 대출 처리와 동시에 반납 예정일이 반드시 설정되어야 합니다.
• 대출 시점에 도서의 물리적 상태가 확인되어야 합니다.
• 대출 이력은 영구적으로 보관되어야 합니다.

4.3 애그리거트 도출 단계에서의 불변식 정리

애그리거트를 도출하는 단계에서는 이전 단계들에서 발견된 모든 불변식들을 종합적으로 검토하고 정리합니다. 이 과정에서 불변식들은 각 애그리거트의 책임으로 명확하게 할당됩니다.

BookCopy 애그리거트의 불변식 예시:

상태 관련 불변식:

• 도서는 항상 다음 상태 중 하나를 가져야 합니다: 대출가능, 대출중, 예약중, 훼손, 분실
• 상태 변경은 정해진 규칙에 따라서만 가능합니다(예: 대출가능 → 대출중)

대출 관련 불변식:

• 한 도서의 대출 기록은 시간 순서대로 유지되어야 합니다.
• 대출 연장은 예약이 없는 경우에만 가능합니다.
• 연장은 1회로 제한됩니다.

Member 애그리거트의 불변식 예시:

대출 한도 관련 불변식:

• 동시 대출 권수는 회원 등급별 한도를 초과할 수 없습니다.
• 연체 중인 도서가 있는 경우 추가 대출이 제한됩니다.

회원 상태 관련 불변식:

• 회원은 항상 하나의 명확한 상태를 가져야 합니다.
• 자격 정지 상태에서는 모든 도서관 서비스 이용이 제한됩니다.

4.4 불변식 문서화와 검증

식별된 불변식들은 명확하게 문서화되어야 하며, 다음과 같은 형식으로 정리하는 것이 좋습니다:

각 불변식에 대해:

• 설명: 불변식이 의미하는 바를 명확히 기술합니다.
• 범위: 어떤 애그리거트나 엔티티에 적용되는지 명시합니다.
• 검증 시점: 언제 이 규칙이 검사되어야 하는지 정의합니다.
• 위반 시 조치: 규칙 위반 시 어떤 조치를 취해야 하는지 명시합니다.

예시:

불변식: 대출 연장 횟수 제한
- 설명: 도서의 대출 연장은 1회로 제한됩니다.
- 범위: BookCopy 애그리거트
- 검증 시점: 대출연장 커맨드 실행 전
- 위반 시 조치: 연장 요청 거부 및 사유 안내

이렇게 정리된 불변식들은 다음과 같은 목적으로 활용됩니다:

• 시스템 설계의 기준점으로 사용됩니다.
• 테스트 케이스 작성의 기초가 됩니다.
• 구현 시 유효성 검사의 근거가 됩니다.
• 향후 기능 추가나 변경 시 참조 기준이 됩니다.

[기존 내용 계속…]

5. 워크샵 마무리

이벤트 스토밍 워크샵의 성공적인 완료를 위해서는 도출된 결과물을 정리하고, 이를 실제 구현으로 연결하는 후속 작업이 필요합니다.

5.1 결과물 정리

워크샵에서 도출된 다음 항목들을 체계적으로 문서화합니다:

도메인 모델 구조:

• 식별된 애그리거트와 그 구성요소
• 애그리거트 간의 관계
• 주요 도메인 규칙과 정책

이벤트 흐름:

• 핵심 비즈니스 프로세스의 이벤트 체인
• 자동화된 정책과 프로세스
• 예외 상황과 대응 방안

5.2 구현 계획 수립

도출된 설계를 실제 시스템으로 구현하기 위한 계획을 수립합니다:

단계별 구현 전략:

• 핵심 애그리거트부터 순차적 구현
• 테스트 전략과 품질 보증 방안
• 배포와 운영 전환 계획

이를 통해 이벤트 스토밍 워크샵의 결과물이 실제 가치 있는 시스템으로 구현될 수 있도록 합니다.