도메인 스토리텔링(DST)이란?

개요

• 최근 팀이 더 나은 설계를 위해 도메인 주도 설계(DDD) 도입을 결정하고 R&D를 진행함
• DDD 이론을 학습하면서 유비쿼터스 언어, 바운디드 컨텍스트 같은 개념은 이해했지만 막상 “우리 비즈니스의 경계는 어디인가?”라는 질문 앞에서 막막함을 느낌
• 구체적인 비즈니스 프로세스를 시각화해서 모두가 같은 그림을 보고 이야기할 필요가 있다고 판단
• 이 과정에서 도메인 스토리텔링(Domain Storytelling, DST)을 알게 되었고 DDD 도입의 첫 단계로 시도해보기로 함
• DST를 통해 추상적이었던 논의가 구체적인 시나리오로 바뀌었고 자연스럽게 유비쿼터스 언어와 컨텍스트 경계를 발견하는 경험을 함

도메인 스토리텔링이란

• 도메인 스토리텔링(Domain Storytelling, DST)은 도메인 전문가와 개발자가 협업해 비즈니스 프로세스를 시각적인 이야기로 그려내는 모델링 기법
• 워크숍 형태로 진행되며 실제 업무를 수행하는 사람들이 자신의 일을 “이야기”로 풀어내면 진행자가 픽토그램(그림 언어)으로 실시간 기록
• 복잡한 비즈니스 프로세스를 구체적인 시나리오로 표현해 팀 전체가 동일한 그림을 보며 대화할 수 있게 함

DDD와의 관계

• 도메인 주도 설계(DDD)를 도입할 때 가장 어려운 점은 “우리 비즈니스의 경계는 어디인가?”라는 추상적인 질문에 답하는 것
• DST는 구체적인 업무 시나리오를 그려내는 과정에서 자연스럽게 다음을 발견하게 함
  • 유비쿼터스 언어(Ubiquitous Language)
    • 스토리에서 사용된 액터, 작업 객체, 활동의 이름
  • 바운디드 컨텍스트(Bounded Context)
    • 밀접하게 관련된 액터와 작업 객체의 그룹
• DDD의 전략적 설계를 시작하기 전 팀의 공통 이해를 만드는 효과적인 출발점

DST의 기본 픽토그램

• 아래 픽토그램은 Egon.io와 오프라인 워크숍 모두에서 공통으로 사용하는 시각 언어

• 액터(Actor)
  • 업무를 수행하는 주체 (사람, 조직, 시스템)
  • 사람 형태 아이콘 사용
  • 색상으로 책임 영역 구분 가능
  • 
• 작업 객체(Work Object)
  • 액터가 생성/사용하는 대상 (문서, 데이터, 물건)
  • 사각형 카드 형태
  • CRUD 작업의 대상
  • 
• 활동(Activity)
  • 액터가 수행하는 동작 (동사)
  • 화살표로 표현
  • 동사형으로 간결하게 작성
  • 
• 순번(Sequence Number)
  • 활동의 발생 순서 (1), (2), …
  • 스토리의 시간 흐름 표현
  • 
• 주석(Annotation)
  • 비즈니스 규칙, 제약 조건, 질문
  • 중요한 규칙 기록
  • 미해결 항목을 백로그로 관리
  • 
• 그룹/경계(Group/Boundary)
  • 동일 책임 영역의 시각적 묶음
  • 바운디드 컨텍스트 후보 식별
  • 

DST 워크숍 진행 방법

준비

• 참여자 구성
  • 도메인 전문가
    • 실제 비즈니스 프로세스를 가장 잘 아는 사람
  • 기술 전문가
    • 시스템을 구현하거나 운영할 개발자
  • 진행자
    • 워크숍 흐름을 조율하고 질문을 던지는 중립적 역할
• 도구 선택
  • 오프라인
    • 화이트보드, 마커, 포스트잇
  • 온라인
    • Miro, FigJam, Egon.io
  • Egon.io 추천 이유
    • DST 시각 언어를 네이티브 지원
    • 브라우저에서 무료로 사용 가능
    • .egn (JSON 기반) 및 .svg 포맷 지원
    • 링크 공유로 실시간 협업 가능
  • Egon.io 활용 팁
    • 설치 없이 브라우저에서 즉시 실행
    • 좌측 팔레트에서 아이콘을 드래그하면 자동으로 순번 생성
    • Export 메뉴에서 .egn (버전 관리용)과 .png (공유용) 동시 저장
• 범위 정하기
  • 한 번에 모든 시나리오를 다루지 말고 가장 중요한 하나의 흐름부터 시작
  • “고객이 상품을 주문하는 과정”, “수강생이 강의를 신청하는 과정” 같은 구체적인 시나리오 선택

진행 순서

• 1단계 - 도메인 스토리 찾기
  • 진행자가 도메인 전문가에게 구체적인 예시를 요청
  • “가장 최근에 처리한 주문은 어떻게 진행되었나요?”
  • “수강 신청이 들어오면 가장 먼저 무슨 일이 일어나나요?”
• 2단계 - 도메인 스토리 기록하기
  • 진행자가 픽토그램을 사용해 전문가의 이야기를 실시간 시각화
  • “누가(Actor), 무엇을(Activity), 어떤 것(Work Object)으로 작업하나요?” 반복 질문
  • 활동마다 순번을 매겨 흐름 명확화
• 3단계 - 이야기 함께 검토하기
  • 완성된 다이어그램을 보며 진행자가 이야기를 다시 설명
  • 참여자들이 이해가 일치하는지 확인
  • 잘못된 부분 수정, 누락된 정보 보충
• 4단계 - 경계와 언어 발견하기
  • 서로 밀접하게 관련된 액터와 작업 객체 그룹 찾기
  • 이 그룹들이 바운디드 컨텍스트의 후보
  • 스토리에서 사용된 용어들을 유비쿼터스 언어로 정리

시작하기

• DST는 특별한 도구 없이도 화이트보드 하나로 시작 가능
• 가장 중요한 것은 도메인 전문가와 개발자가 함께 모여 구체적인 이야기를 나누는 것
• 작은 시나리오 하나부터 시작해 점진적으로 확장
• Egon.io에서 무료로 연습해볼 수 있음

예시 시나리오 - 온라인 강의 플랫폼 수강 신청 흐름

• 온라인 강의 플랫폼의 수강 신청부터 수료증 발급까지의 전체 프로세스를 DST로 모델링
• 이 과정에서 컨텍스트 경계와 유비쿼터스 언어가 어떻게 드러나는지 확인

스토리 시작 - 수강생 영역

• (1) 수강생 액터가 강의 목록을 조회함
• (2) 수강생 액터가 원하는 강의를 선택함
• (3) 수강생 액터가 강의를 수강 바구니에 담음

• (4) 수강생 액터가 수강 바구니에서 수강 신청서를 작성함

  

  • 수강생 1명이 순차적으로 4가지 활동을 수행
  • 모든 활동이 수강생 액터에서 시작하여 각 작업 객체로 연결
  • 순번 (1) → (2) → (3) → (4)로 시간 흐름 표현

시스템 연동 - 결제 영역

• (5) 수강생 액터가 수강 신청서를 결제 시스템에 전송함

• (6) 결제 시스템 액터가 결제 완료 정보를 수강 관리 시스템에 전달함

  

  • 수강생, 결제시스템, 수강관리시스템 3개 액터가 등장
  • 수강신청서가 결제시스템으로 전달되고, 결제완료정보가 수강관리시스템으로 전달되는 흐름
  • 시스템 간 데이터 전달을 명확히 표현

유비쿼터스 언어 발견 - 수강 관리팀 영역

• 수강 관리팀 전문가는 결제 완료 정보가 접수되면 이를 확정 수강이라 부름
• 진행자는 Egon.io 주석 기능으로 확정 수강의 정의를 기록해 용어 사전 보강
• (7) 수강 관리 시스템 액터가 확정 수강 정보를 바탕으로 수강권을 생성함

• (8) 수강 관리 담당자 액터가 수강권을 수강생에게 발급함

  

  • 수강관리시스템과 수강관리담당자가 각각 독립적인 활동 수행
  • “확정수강”이라는 유비쿼터스 언어가 작업 객체로 등장
  • 시스템이 생성하고 담당자가 발급하는 2단계 프로세스 표현

바운디드 컨텍스트 경계 확인 - 강의 제공 영역

• (9) 수강 관리 담당자 액터가 수강권 정보를 강의 제공 시스템에 전달함
  • 여기서 수강 관리 컨텍스트에서 강의 제공 컨텍스트로 책임이 넘어감
• (10) 강의 제공 시스템 액터가 수강권 정보를 기반으로 학습 진도를 초기화함
• (11) 수강생 액터가 강의 영상을 시청함

• (12) 강의 제공 시스템 액터가 학습 진도를 업데이트함

  

  • 3개 독립적인 활동 흐름으로 구성
  • (9) → (10): 수강권정보 전달 및 학습진도 초기화
  • (11): 수강생의 강의 시청 활동
  • (12): 시스템의 진도 업데이트 활동
  • 컨텍스트 경계가 명확히 표현됨

수료 처리 영역

• (13) 수강생 액터가 수료 신청서를 제출함
• (14) 강의 제공 시스템 액터가 학습 진도와 수료 조건을 검증함
• (15) 수강 관리 담당자 액터가 수료증을 발급함

• (16) 수강생 액터가 수료증을 다운로드함

  

  • 3단계 구조로 수료 프로세스 표현
  • (13) → (14): 신청 및 검증 (시스템이 학습진도와 수료조건 2가지 확인)
  • (15): 담당자의 수료증 발급
  • (16): 수강생의 수료증 다운로드
  • 수강생이 처음과 마지막에 등장하여 프로세스의 시작과 끝을 명확히 표현

전체 흐름 통합 다이어그램

• 위 5개 영역을 하나의 다이어그램으로 통합한 전체 플로우

• 수강 신청부터 수료증 다운로드까지의 완전한 흐름을 한눈에 확인 가능

  

  • 16개 순차적 활동으로 전체 프로세스 표현
  • 5개 영역(수강생 → 결제 → 수강권 발급 → 강의 제공 → 수료 처리)의 자연스러운 연결
  • 각 컨텍스트 간 데이터 전달 지점이 명확히 표시됨

이 스토리에서 발견한 것들

유비쿼터스 언어

• 워크숍을 진행하면서 도메인 전문가가 사용한 용어들을 기록
• 특히 “확정 수강”은 개발자들이 처음 들었던 용어로, 주석 기능으로 정의를 명확히 함

• 이렇게 발견된 용어들이 팀의 공통 언어가 되어 코드와 문서에 일관되게 사용됨

• 확정 수강
  • 결제 완료 후 정식으로 등록된 수강 상태
  • 이 시점부터 수강권 발급이 가능해짐
• 수강권
  • 강의에 접근할 수 있는 권한
  • 물리적 카드가 아닌 시스템 내 권한 개념
• 학습 진도
  • 수강생의 강의 수강 진행률
  • 수료 조건 판단의 핵심 데이터
• 수료 조건
  • 수료증 발급을 위한 요구사항
  • 진도율, 퀴즈 점수 등 복합 조건

바운디드 컨텍스트 후보

• 도메인 스토리를 그리는 과정에서 자연스럽게 3개의 컨텍스트 경계가 드러남

• 각 컨텍스트는 서로 다른 핵심 책임과 액터, 작업 객체를 가짐

• 수강 관리 컨텍스트
  • 핵심 책임
    • 수강 신청, 결제, 수강권 발급
  • 주요 액터
    • 수강생, 수강 관리 담당자, 결제 시스템
  • 작업 객체
    • 수강 신청서, 결제 완료 정보, 확정 수강, 수강권
  • 특징
    • 수강생의 등록과 권한 관리에 집중
• 강의 제공 컨텍스트
  • 핵심 책임
    • 강의 시청, 학습 진도 관리, 수료증 발급
  • 주요 액터
    • 수강생, 강의 제공 시스템
  • 작업 객체
    • 수강권 정보, 학습 진도, 강의 영상, 수료 조건, 수료증
  • 특징
    • 실제 학습 활동과 진도 추적에 집중
• 결제 컨텍스트
  • 핵심 책임
    • 결제 처리
  • 주요 액터
    • 결제 시스템
  • 작업 객체
    • 수강 신청서, 결제 완료 정보
  • 특징
    • 외부 시스템으로 독립적인 영역

컨텍스트 간 상호작용

• 수강 관리 → 결제
  • 수강 신청서 전달
• 결제 → 수강 관리
  • 결제 완료 정보 전달
• 수강 관리 → 강의 제공
  • 수강권 정보 전달

DST가 DDD에 주는 이점

추상적 논의를 구체적 시나리오로 전환

• “바운디드 컨텍스트가 뭐지?”라는 질문 대신
• “수강권을 발급하는 팀과 강의를 제공하는 팀의 책임이 다르네요”라는 구체적 발견

팀 전체의 공통 이해 형성

• 도메인 전문가, 개발자, 기획자가 같은 그림을 보며 대화
• 오해와 누락을 워크숍 단계에서 조기 발견

용어 사전의 자연스러운 축적

• 워크숍에서 사용된 용어를 즉시 정리
• 코드와 문서에 동일 용어 적용 가능

전략적 설계의 탄탄한 기반 마련

• 유비쿼터스 언어와 바운디드 컨텍스트 후보 확보
• 이후 컨텍스트 맵 작성 시 명확한 출발점 제공

Reference

• Domain Storytelling 공식 사이트
• Egon.io - DST 온라인 도구
• Stefan Hofer, Henning Schwentner. (2021). Domain Storytelling: A Collaborative Modeling Method