도메인 주도 설계(DDD) 이벤트 스토밍 워크숍 실천 가이드

💡 핵심 요약 (Executive Summary)

본 가이드는 concept DDD 이벤트스토밍 핵심 가이드 및 실전 아키텍처의 핵심 개념, 실전 구성 명령어 및 아키텍처 베스트 프랙티스를 다룹니다. 클라우드 네이티브 및 인프라 엔지니어링 실무에 즉시 활용 가능하도록 체계적으로 정리했습니다.

📑 Table of Contents
MSA 기반 설계 수행 절차
  1. 마이크로서비스 도출
  2. 도메인 식별 및 데이터간 관계정의
  3. 마이크로서비스 식별
  4. 내부아키텍처 정의
  5. 기관시스템 특성을 반영한 MSA기반 설계 원칙 수립
  6. 현황분석/비즈니스 요건 기반 마이크로 서비스 설계
  7. 외부아키텍처 정의
  8. 최적 기술 적용을 위한 참조모델 선정
  9. 기술요소별 최적화설계(논리/물리)
  10. 용량 및 비용설계
  11. 서비스 구축을 위한 인프라용량(컨테이너 관점) 설계
  12. MSA기반
마이크로 서비스 도출 방법
  • 마이크로 서비스를 도출하는 방법은 비즈니스 기능별 분해 방법과 도메인 주도 설계 방법이 있음
  • 비즈니스 기능별 분해
  • 기능 Tree 기준 3Depth 분류 및 세부 기능설명
  • 도메인 주도 설계(DDD)
  • 비즈니스 도메인을 구성하는 하위 서브도메인 기준으로 서비스 분해하여 높은 응집도와 낮은 결합도
  • 도메인: 비즈니스 목표 혹은 그보다 작은 기능목표단위(서브도메인)
도메인 주도 설계
  • 개발자들과 설계자가 함께 설계회의
  • 코드 이전에 도메인과 도메인모델의 완전한 이해
  • 코드와 모델을 밀접하게 관련시킴
  • 크고 복잡한 도메인을 이해하고 탐구하는 활동
용어와 코어내용
  • 바운디드 컨텍스트
  • 도메인간의 경계를 식별
  • 유비쿼터스 언어
  • 프로젝트 수행인력이 공통으로 사용하는 언어
  • 핵심 서브 도메인
  • 비즈니스 특화
  • 지원 서브 도메인
  • 옵셔널한 영역
  • 일반 서브 도메인
  • 비즈니스 특화 X
  • 전략적 설계
  • 마이크로 서비스를 식별하는 역할
    • 설계가 계속해서 커지게 되면 중요도 기준 분류 필요
    • 큰 도메인을 서브도메인으로 분리해서 핵심, 지원, 일반 서브도메인으로 나눔
    • 바운디드 컨텍스트는 1:1 or 1:N
    • 컨텍스트간의 관계를 찾아 Context Map 작성
  • 설계 과정
    1. bounded context 내부를 모델링하기 위한 유비쿼터스 언어를 정의
    2. 위의 공통된 언어 분석하여 비즈니스를 분석하고 핵심개념을 식별
    3. 식별 개념들을 분석해서 Bounded Context 식별
    4. Bounded context의 매핑관계를 정의하여 Context Map 작성
    5. 분할에 따른 효과를 분석하여 분할 혹은 통합
    6. 마이크로서비스 정의
  • 전술적 설계
  • 이벤트 스토밍
    • 수행 방법
      1. 도메인 이벤트 찾기
      2. 커맨드 정의 및 커맨드 사용자 식별
      3. 도메인을 서브도메인으로 분류
  • 참여자: 이해관계자
    • 도메인 전문가
    • 분석가
    • 제품 책임자
    • 개발자
  • 준비물:
    • 포스트잇
    • 대형 롤페이퍼
  • 장소:
    • 의자가 없는 넓은 벽면의 공간
  • 기본 수행 절차:
    1. 도메인 이벤트 (오렌지색)
      – 시간 순서로 부착
      – 과거형 문장으로 적음 (음슴체)
      – 유비쿼터스 언어를 사전정의하여 중복되거나 중의적인 단어사용을 하지 않도록 함
    2. 프로세스 / 외부 시스템 (핑크색)
      – 도메인 이벤트가 하나 또는 여러단계의 실행 프로세스를 호출하는 경우
      – 외부 시스템과 연계가 필요한 경우
    3. 핫스팟 (자주색)
      – 질문 / 가정 / 경고 / 의견 수렴이 필요한 경우 작성

      • 도메인 이벤트나 프로세스 / 외부 시스템에 대하여
      • 결정짓기 애매한 필수/선택 값의 경우등도 이렇게 Throw함
    4. 커맨드 (파란색)
      – API 혹은 Function 단위일 수 있음
      – 배치성 도메인 이벤트의 경우에는 커맨드가 없을 수 있음
      – 도메인 이벤트로 인하여 발생하거나, 도메인 이벤트의 원인이 될 수 있음
    5. 액터 (연한 노란색, 작은 포스트잇)
      – 커맨드 아래에 붙임
      – 커맨드를 실행하는 사용자 (유비쿼터스 언어로 명시)
    6. 도메인을 여러개의 서브도메인으로 나누는 활동의 차례
    7. 엔티티/에그리것 (진한 노란색, 큰 포스트잇)
    8. 커맨드 → 도메인 이벤트 사이에 겹쳐서 붙임
    9. 특정 ID를 가지는 개체특성의 레코드나, 커맨드로 이루어낸 결과
    10. 바운디드 컨택스트 식별
    11. 식별 후에 서브도메인 간의 통신이 동기식인지 비동기식인지 표기
    12. 마이크로서비스 식별
    13. 기능적 유사점이 존재하는 동일한 바운디드 컨택스트에서도 기능개발이 주로 이루어지는 부분과 이루어지지 않을 부분을 나누어 기능단위를 작게 분할할 수 있음
  • 고급 수행 절차:
    1. 읽기 모델(Read Model) (초록색)
    2. 사용자가 커맨드를 수행함에 있어 결정근거가 되는 데이터
    3. User Interface (하얀색)
    4. 스케치 형태의 화면 레이아웃
    5. 정책(Policy) (하늘색)
    6. 이벤트 조건에 따라 진행되는 결정 (IF)
인사이트
  • 일반적인 소프트웨어 설계시 생기는 비 절차적인 추가기능 등으로 인하여 복잡한 코드가 탄생

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *