책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 17일차 (~146p)

요약

• 5장. 마이크로서비스 설계 나머지 부분에 대해 이해함.
  • 이벤트 스토밍을 통한 마이크로서비스 도출
    • 이벤트 스토밍 워크숍 진행
      1. 도메인 이벤트 찾기
      2. 외부 시스템 도출
      3. 커맨드 도출
      4. 핫스폿 도출
      5. 액터 도출
      6. 애그리거트 정의
      7. 바운디드 컨텍스트 그리기
      8. 컨텍스트 매핑

메모

5.4.2 이벤트 스토밍 워크숍 진행

• 이벤트 스토밍 워크숍은 체력 소모가 크고 2시간이 넘어가면 집중력이 떨어짐.
  • 따라서, 워크숍의 진행 시간은 최대 3시간을 넘지 않도록 해야 함.
  • 만약 시간 내에 워크숍을 완료하지 못하는 경우, 하루나 이틀 후에 추가 워크숍을 진행하는 것이 좋음.
• 이벤트 스토밍은 다음과 같은 순서로 진행됩니다:
  1. 도메인 이벤트 찾기
  2. 외부 시스템/외부 프로세스 찾기
  3. 커맨드 찾기
  4. 핫스폿 찾기
  5. 액터(사용자/역할) 찾기
  6. 애그리거트 정의하기
  7. 바운디드 컨텍스트 정의하기
  8. 컨텍스트 매핑하기
• 워크숍의 예시로, 상품을 판매하는 사람과 구매하는 사람을 이어주는 쇼핑몰 서비스가 주어짐.
  • 판매자는 쇼핑몰 서비스에 상품을 등록하고, 구매자는 필요한 상품을 주문함.
  • 주문이 이루어지면 판매자가 상품을 발송하는 시스템임.
  • 워크숍은 도메인 이벤트를 도출하는 것부터 시작함.

1. 도메인 이벤트 찾기

• 도메인 이벤트 찾기 단계에서는 시간의 흐름에 따라 시스템의 동작을 의미하는 도메인 이벤트를 도출함.
  • 이때, 데이터나 데이터의 구조가 아닌 비즈니스 흐름에서 발생한 이벤트에 초점을 두어야 함.
  • 참여자들은 오렌지색 포스트잇에 이벤트명을 작성해서 붙임.
  • 이벤트명은 과거형 동사로 작성함.
• 이벤트는 왼쪽에서 오른쪽으로 시간 흐름순으로 붙이며, 이벤트가 연쇄적으로 발생하는 경우 바로 옆에 붙임.
  • 같은 시점에 비즈니스 조건에 따라 대체적으로 발생할 수 있는 이벤트는 세로로 아래쪽에 같은 선상에 붙임.
• 도메인 이벤트는 비즈니스의 상태를 생성, 변경, 삭제하는 요소임.
  • 시스템의 화면을 생각하지 않고, 비즈니스가 흘러감에 따라 비즈니스를 구성하는 요소들의 상태가 어떻게 변경되는지를 생각함.
• 예를 들어, 회원가입 후 사용할 수 있는 시스템에서는 도메인 이벤트로 [회원 가입됨], [회원정보 수정됨], [회원정보 삭제됨]을 도출할 수 있음.
  • 쇼핑몰 예시에서는 회원가입 후 상품이 등록되고, 주문과 배송이 이뤄지는 과정을 이벤트로 파악함.

2. 외부 시스템 도출

• 외부 시스템 도출 과정에서는 이벤트를 도출하며 업무의 흐름이 레거시 시스템이나 외부 시스템과의 연계를 통해 진행될 때, 해당 프로세스의 이름을 핑크색 스티커에 작성함.
  • 이 스티커를 이벤트의 오른쪽 상단에 붙이고 화살표를 그려 외부 시스템을 호출한다는 것을 표시함.
• 시스템 구현 범위에 있는 기능이 아니더라도, 시스템의 기능 구현을 위해 연계가 필요한 시스템들은 모두 도출해야 함.
  • 시스템 이름은 명사 형태로 적음.
• 예를 들어, 회원가입이나 회원 정보 수정 시에 회원 정보의 유효성을 판단하는 시스템과 연계하고, [주문 아이템 주문됨] 이벤트와 연계되는 외부의 [결제 시스템], [결제 승인됨] 이벤트와 연계되는 [이메일 시스템]을 도출할 수 있음.

3. 커맨드 도출

• 커맨드 도출은 도메인 이벤트를 동작시키는 요인을 찾는 과정임.
  • 이는 파란색 포스트잇에 작성되며, 명령형 즉 동사 형태로 표현됨.
  • 도메인 이벤트를 통해 커맨드를 유추할 수 있음.
• 하나의 커맨드가 여러 이벤트를 동시 또는 연속으로 발생시킬 수 있고, 조건에 따라 하나의 커맨드로 여러 다른 이벤트가 발생할 수 있음.
  • 예를 들어, [회원 가입됨] 이벤트를 동작시키는 [회원가입] 커맨드, [상품 등록됨] 이벤트를 동작시키는 [상품등록] 커맨드 등이 있음.

4. 핫스폿 도출

• 핫스폿 도출은 워크숍 진행 중 발생하는 의문사항, 결정하기 어려운 사항, 외부 문의가 필요한 사항 등을 기록하는 과정임.
  • 이는 보라색 스티커에 기록되어 문제가 되는 위치에 붙여짐.
• 워크숍 중 어느 때든지 발생할 수 있으며, 이들은 별도로 관리될 수 있는 사항에 해당함.
  • 예를 들어, [상품 주문 취소] 커맨드 옆에 [취소 가능 시점 확인]이라는 핫스폿이 붙어 있을 수 있음.

5. 액터 도출

• 액터 도출은 커맨드를 실행하는 사용자나 조직, 역할자를 식별하는 과정임.
  • 액터는 비즈니스를 수행하는 구체적인 역할을 고려하여 식별하며, 특정 비즈니스를 실제로 수행하는 판매자, 구매자, 상품 관리자 등으로 정의함.
• 액터 도출 과정에서 이전에 식별하지 못했던 커맨드와 도메인 이벤트가 추가로 도출될 수 있음.
  • 이때, 추가로 식별되는 사항들은 모델링 공간에 붙여짐.
• 액터는 노란색 포스트잇에 기록되어 커맨드의 왼쪽 아래에 붙여짐.
  • 이는 액터가 커맨드를 조작한다는 것을 명시적으로 표현함.
  • 예를 들어, 액터가 [판매자], [구매자], [주문자] 등으로 구체화되어 있을 수 있음.
• 액터를 도출하며, 커맨드와 이벤트를 검토하고 문장을 만들어 확인함.
  • 만약 문장이 자연스럽지 않다면, 커맨드와 도메인 이벤트를 변경하거나 새롭게 도출함.
• 이런 방식으로 도메인 이벤트, 외부 시스템, 커맨드, 액터를 찾아내면 전체 시스템의 큰 그림을 볼 수 있음.
  • 액터를 식별함으로써 주요 사용자나 역할자의 주요 프로세스도 그려볼 수 있으며, 프로세스 중간중간에 붙어있는 핫스폿을 통해 프로세스 구현에 필요한 이슈나 문제, 해결할 사항들을 파악할 수 있음.
  • 이렇게 비즈니스 관점에서 워크숍을 진행한 후에는 설계 수준으로 진행하게 됨.

6. 애그리거트 정의

• 애그리거트는 커맨드와 도메인 이벤트가 영향을 주는 데이터 요소로, 도메인의 실체 개념을 표현하는 객체인 엔티티가 됨.
  • 애그리거트는 노란색 포스트잇에 애그리거트명을 작성하여 커맨드와 도메인 이벤트 사이의 상단에 겹쳐서 붙임.
• 애그리거트를 구체적으로 식별하는 것이 중요한 이유는, 이것이 컨텍스트의 경계를 식별하는 데 유용하기 때문임.
  • 예를 들어, '회원'이라는 애그리거트가 식별될 수 있음.
  • 또한, 애그리거트는 [회원], [결제], [상품], [배송] 등으로 정의될 수 있음.

7.  바운디드 컨텍스트 그리기

• 애그리거트의 일부는 이름이 같거나 유사하며, 이들을 완전히 다른 애그리거트와 구분하여 바운디드 컨텍스트를 그림.
  • 바운디드 컨텍스트는 도메인 이벤트, 커맨드, 액터, 애그리거트를 모두 고려하여 식별하며, 수정 가능한 라인 테이프로 표시하는 것이 좋음.
• 바운디드 컨텍스트에는 이름을 부여하며, 컨텍스트의 이름은 바운디드 컨텍스트 내의 애그리거트 이름으로 정의함.
  • 만일 컨텍스트 내에 여러 개의 애그리거트 이름이 있는 경우, 전체를 아우를 수 있는 대표 이름을 정함.
• 동일한 이름의 애그리거트가 서로 다른 공간에 떨어져 있는 경우, 해당 애그리거트가 많이 식별된 위치로 모든 관련 포스트잇을 옮길 수 있음.
  • 이는 기능을 제공할 책임들을 응집성 있도록 동일한 애그리거트 중심으로 모듈화해야 함을 의미함.
• 예를 들어, [상품], [카테고리]를 도출했을 때, 이 둘 사이에 경계를 둘 수도 있지만, 여기서는 상품과 카테고리를 묶어 [상품]이라는 바운디드 컨텍스트로 정의했음.
  • 또 다른 예로, [구매] 컨텍스트에 [주문], [결제], [주문아이템]이 애그리거트로 식별되었지만, 주문할 아이템을 검색한 후 주문에서 결제까지 하나의 흐름으로 이어지기 때문에 각각을 분리하지 않고 [구매] 컨텍스트로 묶어서 정의했음.

정책을 도출하면서 연관관계 생각하기

• 바운디드 컨텍스트와 외부 시스템들 간의 관계를 그릴 수 있음.
  • 그 다음 단계는 정책 도출임.
  • 정책은 반응적인 비즈니스 로직으로, 특정 도메인 이벤트가 발생할 때 항상 특정 커맨드를 실행하게 함.
  • 정책은 도메인 이벤트와 커맨드 사이에 위치하며, 호출하는 커맨드는 같은 또는 다른 바운디드 컨텍스트에 존재할 수 있음.
• 정책을 도출함으로써 다른 바운디드 컨텍스트와의 관계를 식별할 수 있음.
  • 예를 들어, 구매가 완료되거나 취소되는 경우에, 상품의 재고 수량이 변경되어야 한다는 정책을 도출할 수 있음.
  • 이는 구매 바운디드 컨텍스트에서 '구입완료됨' 또는 '결제취소됨' 이벤트가 발생한 후 '재고변경'이라는 정책으로 인해 상품 바운디드 컨텍스트의 '상품재고수정' 커맨드가 호출되는 것을 의미함.
• 또한, 구매 컨텍스트에서 구매가 완료되면 '배송요청됨'이라는 이벤트가 발생하고, 이 이벤트와 연관된 '배송생성'이라는 정책으로 배송 컨텍스트의 '배송접수'라는 커맨드를 트리거하는 것을 알 수 있음.
  • 흐름의 방향은 파란색 라인 테이프를 통해 화살표로 표현됨.

8. 컨텍스트 매핑

• 바운디드 컨텍스트 식별 및 관계 파악 후 컨텍스트 맵을 통해 이를 표현함.
  • 호출 관계의 방향과 호출 방식 (동기 or 비동기)를 고려해야 함.
  • 동기 호출은 데이터의 일관성과 컨텍스트의 가용성을 고려하며, 필요한 관계는 동기 호출로, 결과적 일관성으로 충분한 관계는 비동기 호출로 표현함.
• 동기 방식은 실시간 동시 처리를 위해 호출하고 응답을 대기하는 방식이며, 의존도가 높아짐.
  • 비동기 방식은 이벤트 발행 후 연관된 다른 컨텍스트가 이벤트를 받아 처리하는 방식으로 의존성을 낮춤.
  • 실시간 정합성이 필요하지 않은 경우 비동기 연계를 고려하면 독립성과 탄력성이 강화됨.
• 컨텍스트 맵 작성시 바운디드 컨텍스트명을 스티커에 적어 관계를 표현하며, 동기 호출은 실선으로, 비동기 호출은 점선으로 표현함.
• 예로, 구매 컨텍스트는 상품 컨텍스트와 회원 컨텍스트와 동기 방식으로 연동하나, 배송 컨텍스트와는 비동기로 연결함.
  • 이렇게 설정하면 배송 컨텍스트에 장애가 발생해도 주문 처리의 고가용성이 보장됨.
• 비동기 연계는 독립성과 높은 가용성을 보장하므로, 동기 연동은 꼭 필요한 경우에만 사용하고 많은 부분에 비동기 연동을 통해 데이터 정합성을 맞추는 경우가 많아졌음.
• 도출된 바운디드 컨텍스트는 마이크로서비스 후보가 됨.
  • 최종적으로 마이크로서비스로 정의하려면 추가로 비즈니스 측면, 데이터 관점, 운영 조직 측면, 배포 측면, 변경 영향도, 클라우드/MSA 도입 목적 측면을 고려해 판단함.
• 이벤트 스토밍 결과는 프로젝트가 진행되는 공간에 그대로 붙여 놓아 계속 보완하고 리뷰될 수 있게 하는 것이 좋음.
  • 최종적인 문서나 협업 시스템에 기록을 남기는 것도 중요함.
  • 이렇게 만들어진 컨텍스트 맵은 마이크로서비스의 도메인 모델, 애플리케이션 아키텍처, 이벤트 플로우 등을 설계하는데 사용됨.

마이크로서비스 상세 설계를 위한 입력물

• 이벤트 스토밍 결과는 마이크로서비스 상세 설계의 출발점이 됨.
  • 마이크로서비스별로 커맨드, 도메인 이벤트, 애그리거트, 서비스 연계 및 정책, 핫스팟, API, 도메인 이벤트, 데이터, 리스크 등을 정리할 수 있음.
  • 이 자료는 마이크로서비스의 프런트엔드 모델링과 백엔드 모델링에 활용됨.