[개발서적] 도메인 주도 설계 첫걸음 3부(ch12~13) 요약 (2)

Ch12. 이벤트스토밍

---

 

이번 장에서는 이벤트스토밍에 대해 알아보자.

이벤트스토밍은 사실상 도메인 지식을 공유하고 유비쿼터스 언어를 구축하는 방법 중 하나다.

 

[이벤트스토밍이란?]

이벤트스토밍은 사람들이 모여 비즈니스 프로세스에 관해 브레인스토밍을 하고 신속하게 모델링 하기 위한 로우테크 활동이다.

어떻게 보면 비즈니스 도메인 지식을 공유하기 위한 전술적 도구다.

 

이벤트스토밍에는 범주(scope), 즉 참가자가 다룰 비즈니스 프로세스가 있다.

참가자는 포스트잇을 활용하여 일련의 도메인 이벤트를 시간의 흐름에 따라 표현한다.

 

모델의 모든 구성요소가 비즈니스 프로세스의 작동 방식을 설명할 때까지 단계별로 액터, 커맨드, 외부 시스템 등의 개념을 모델에 추가하여 개선한다.

 

[이벤트스토밍에 무엇이 필요한가?]

이벤트스토밍 세션을 진행하는데 무엇이 필요한지 살펴보자.

 

모델링 공간

• 큰 모델링 공간이 필요하다.

포스트잇

• 색깔이 다양한 많은 양의 포스트잇이 필요하다.

마커

• 포스트잇에 적을 때 쓸 마커가 필요하다.

간식

• 일반적으로 이벤트스토밍 세션은 두 시간에서 네 시간 정도 소요되니 간식을 준비하자.

회의실

• 넓은 회의실이 필요하다.

그림 12-1. 이벤트스토밍을 위한 모델링 공간

 

[이벤트스토밍 과정]

이벤트스토밍 워크숍은 일반적으로 10단계로 진행된다.

 

1단계: 자유로운 탐색

탐색하려는 비즈니스 도메인에 관련된 도메인 이벤트(domain event)를 브레인스토밍하는 것부터 시작된다.

 

그림 12-2. 자유로운 탐색

 

이 단계에서 모든 참가자는 같은 색의 포스트잇으로 무엇이든 떠오르는 도메인 이벤트를 적어서 붙인다.

 

2단계: 타임라인

다음으로, 참가자는 생성된 도메인 이벤트를 읽어보고 그것을 비즈니스 도메인에서 발생하는 순서대로 정리한다.

 

그림 12-3. 자유로운 탐색

 

성공적인 비즈니스 시나리오를 설명하는 흐름인 ‘정상 시나리오’부터 시작한다.

 

3단계: 고충점

일단 시간 순서대로 이벤트를 구성했으면 전체 구성을 보고 프로세스에서 주목할 만한 포인트를 식별한다.

예를 들어, 병목구간, 자동화가 필요한 수작업 단계, 문서가 사라졌거나 도메인 지식이 없는 경우다.

 

그림 12-4. 프로세스에서 주목할 만한 관점을 표시하는 다이아몬드 형태의 핑크색 포스트잇: 예약 프로세스에서 항공권 요금이 어떻게 비교되는지에 관한 사라진 도메인 지식

 

4단계: 중요 이벤트

컨텍스트나 국면이 바뀌는 것을 나타내는 중대한 비즈니스 이벤트를 찾는다.

이를 중요 이벤트(pivotal event)라고 하며, 이 이벤트 전후로 세로로 선을 긋는다.

 

그림 12-5. 이벤트 흐름에서 컨텍스트 변경을 나타내는 중요 이벤트

 

5단계: 커맨드

도메인 이벤트가 이미 발생한 것을 설명하는 반면, 커맨드는 무엇이 이벤트 또는 이벤트의 흐름을 시작하게 하는지를 설명한다.

 

예를 들어

• 캠페인을 게시한다.
• 트랜잭션을 롤백한다.
• 주문을 제출한다.

커맨드는 파란색 포스트잇에 작성해서 커맨드가 생성하는 이벤트 앞에 붙인다.

 

그림 12-6. 고객(액터)이 ‘주문을 제출한다’ 커맨드를 실행한 후, 이어서 세 개의 이벤트가 생성된다.

 

6단계: 정책

대부분의 경우 커맨드에는 관련 액터가 없다. 이 단계에서는 커맨드를 실행할 수도 있는 자동화 정책을 찾는다.

자동화 정책(automation policy)은 이벤트가 커맨드의 실행을 시작하는 시나리오다.

 

그림 12-7. ‘배송이 승인됐다’ 이벤트가 나타날 때 ‘주문을 배송한다’ 커맨드를 실행하는 자동화 정책

7단계: 읽기 모델

읽기 모델은 도메인에서 액터가 커맨드를 실행하는 의사결정을 내릴 때 사용하는 시각적 데이터다.

이것은 시스템의 스크린, 리포트, 알림 등이 될 수 있다.

 

그림 12-8. 고객(액터)이 주문(커맨드)을 제출하는 의사결정을 위해 필요한 ‘쇼핑 카트’ 뷰(읽기 모델)

 

8단계: 외부 시스템

이 단계에서는 외부 시스템 연동 정보를 보강한다.

탐색 중인 도메인에 포함되지 않는 모든 시스템이 외부 시스템에 해당된다.

 

그림 12-9. 커맨드의 실행을 외부 시스템(왼쪽)과 외부 시스템에 전달되는 이벤트의 승인(오른쪽)

 

9단계: 애그리게이트

일단 모든 이벤트와 커맨드가 표현되면 애그리게이트의 개념을 포함하여 모델을 구성할 수 있다.

애그리게이트는 커맨드를 받고 이벤트를 생성한다.

 

그림 12-10. 애그리게이트에 구성된 커맨드와 이벤트

10단계: 바운디드 컨텍스트

이벤트스토밍의 마지막 단계에서는 서로 연관된 애그리게이트를 찾는다.

애그리게이트는 기능이 밀접하게 연관되거나 정책을 통해 연관될 수 있다.

그림 12-11처럼 에그리게이트의 그룹은 바운디드 컨텍스트 경계의 자연스러운 후보가 된다.

 

그림 12-11. 시스템을 바운디드 컨텍스트로 분리한 예시

 

[변형]

이벤트스토밍의 창시자 알베르토 브랜돌리니는 이벤트스토밍의 진행 과정을 반드시 따라야 하는 고정된 규칙이 아니라고 했다.

즉, 여러분의 상황에 잘 맞는 비법을 찾기 위해 자유롭게 실험해도 좋다.

 

[결론]

이벤트스토밍은 협업을 통해 비즈니스 프로세스를 모델링하는 워크숍이다.

도출된 모델 외에도 지식 공유라는 중요한 이점을 얻을 수 있다.

 

 

Ch13. 실무에서의 도메인 주도 설계

---

 

도메인 주도 설계에서 가치를 얻기 위한 모든 패턴을 실무에 적용할 필요는 없다.

적당한 기간 안에, 특히 브라운필드 프로젝트에 모든 DDD 패턴을 적용하고 실무에 도입하는 것은 실질적으로 불가능한 일이다.

 

이번 장에서는 브라운필드 프로젝트와 이상적이지 않은 환경에서 실제로 도메인 주도 설계 도구의 패턴을 적용하기 위한 전략을 배운다.

 

[전략적 분석]

실무에 도메인 주도 설계 패턴을 적용하는 순서에 따라 DDD를 도입하는 가장 좋은 출발점은 조직의 비즈니스 전략과 시스템 아키텍처의 현 상황을 이해하는데 시간을 투자하는 것이다.

 

비즈니스 도메인 이해하기

먼저 회사의 비즈니스 도메인을 파악한다.

• 조직의 비즈니스 도메인은 무엇인가?
• 고객은 누구인가?
• 조직이 고객에게 제공하는 서비스 또는 가치는 무엇인가?
• 경쟁 회사 또는 그들의 제품은 무엇인가?

 

핵심 하위 도메인

회사의 핵심 하위 도메인을 식별하려면 경쟁업체와 차별화되는 점을 찾아라.

• 경쟁업체에 없는 회사의 ‘비법 소스’는 무엇인가?
• 경쟁 우위인 핵심 하위 도메인이 반드시 기술적인 것은 아니라는 점을 명심해라.

핵심 하위 도메인을 식별하는 또 하나의 강력하지만 유감스러운 휴리스틱은 최악으로 설계된 소프트웨어 컴포넌트, 즉 커다란 진흙 덩어리를 찾아내는 것이다.

 

일반 하위 도메인

일반 하위 도메인을 식별하려면 상용 솔루션이나 구독 서비스, 또는 연동할 수 있는 오픈소스 소프트웨어를 찾아라. (ex) 메시징 서비스, 인사 관리 서비스, 권한 관리 서비스 등)

 

지원 하위 도메인

지원 하위 도메인을 식별하려면 상용 솔루션으로 대체할 수 없지만, 직접 경쟁 우위를 제공하지 않는 나머지 소프트웨어 컴포넌트를 찾아라.

 

현재 설계 탐색

문제 도메인에 한 번 익숙해지면 그것의 솔루션 및 설계와 관련된 결정을 계속 살펴볼 수 있다.

먼저 상위 수준 컴포넌트부터 시작하라.

 

그리고 컴포넌트의 특성 중 수명주기를 분리할 수 있는지 찾아라.

하위 시스템이 같은 소스 관리 저장소에서 관리되거나 모든 컴포넌트가 하나의 모놀리식 코드베이스에 있는 경우에도 어느 것이 다른 컴포넌트와 독립적으로 개선되고 테스트되고 배포될 수 있는지 확인하라.

 

전술적 설계 평가

각 상위 수준 컴포넌트에 대해 그것이 어느 비즈니스 하위 도메인을 포함하고 어떤 기술적 설계 의사결정을 내렸는지 확인하라.

비즈니스 로직을 구현하고 컴포넌트의 아키텍처를 정의하는데 어느 패턴을 사용했는가?

 

전략적 설계 평가

상위 수준 컴포넌트에 대한 지식을 사용하여 이러한 컴포넌트가 바운디드 컨텍스트인 것처럼 현재 설계의 컨텍스트 맵을 차트로 표시하라.

그리고 바운디드 컨텍스트 연동 패턴 관점에서 컴포넌트 간의 관계를 식별하고 추적하라.

 

마지막으로 결과 컨텍스트 맵을 분석하고 도메인 주도 설계 관점에서 아키텍처를 평가하라.

 

예를 들어

• 동일한 상위 수준의 컴포넌트에 대해 작업하는 여러 팀
• 핵심 하위 도메인의 중복 구현
• 하청 회사가 핵심 하위 도메인을 구현
• 자주 실패하는 연동으로 인한 마찰
• 외부 서비스와 레거시 시스템에서 확산되는 어색한 모델

 

[현대화 전략]

엔지니어가 시스템을 처음부터 다시 작성하려고 하는 ‘대대적인 재작성(big rewrite)’ 노력은 거의 성공하지 못한다.

전체 시스템을 다시 올바르게 설계하고 구현하기란 매우 어렵다.

 

기존 시스템의 설계를 개선하기 위한 좀 더 안전한 방법은 크게 생각하되 작게 시작하는 것이다.

이를 위해 각 하위 도메인을 제대로 된 바운디드 컨텍스트로 나눈다.

 

대신 그림 13-1과 같이 최소한 논리적 경계(기술 스택에 따라 네임스페이스, 모듈, 패키지)가 하위 도메인의 경계와 일치하는지 확인하는 것부터 시작하자.

 

그림 13-1. 기술적 구현 패턴이 아닌 비즈니스 하위 도메인 경계를 반영하도록 바운디드 컨텍스트의 모듈을 재구성

 

 

 

시스템의 모듈을 조정하는 것은 비교적 안전한 형태의 리팩토링이다.

 

전략적 현대화

논리적 경계를 물리적 경계로 바꿔 바운디드 컨텍스트를 추출하는 과정은 그림 13-2와 같다.

 

다음과 같은 질문을 스스로에게 해보라.

• 여러 팀이 동일한 코드베이스에서 작업하고 있는가?
• 서로 다른 컴포넌트에서 충돌하는 모델을 사용하고 있는가?

 

그림 13-2. 논리적 경계를 물리적 경계로 전환하여 바운디드 컨텍스트 추출

유비쿼터스 언어 육성

성공적인 현대화 설계의 전제조건은 비즈니스 도메인 지식과 비즈니스 도메인의 효과적인 모델을 만드는 것이다.

도메인 지식을 수집하기 위한 도메인 주도 설계의 지름길인 이벤트스토밍을 잊지 말자.

도메인 지식과 해당 모델을 갖췄다면 논의 중인 비즈니스 기능에 가장 적합한 비즈니스 로직 구현 패턴을 결정하라.

 

스트랭글러 패턴

스트랭글러 패턴은 일반적으로 파사드 패턴과 함께 사용된다.

파사드 패턴의 얇은 추상화 계층은 퍼블릭 인터페이스 역할을 하며, 레거시 또는 현대화된 바운디드 컨텍스트로 요청을 전달해 처리하는 역할을 한다.

 

마이그레이션이 완료되면 파사드는 더 이상 필요하지 않으므로 제거한다.

 

그림 13-4. 레거시에서 현대화된 시스템으로 기능을 마이그레이션하는 상태에 따라 요청을 전달하는 파사드 레이어. 마이그레이션이 완료되면 파사드와 레거시 시스템 모두 제거함.

 

바운디드 컨텍스트당 하나의 데이터베이스 규칙을 적용하기 위해 빠르게 레거시 컨텍스트를 폐기하고 현대화된 시스템에서 독점적으로 데이터베이스를 이용한다.

 

그림 13-5. 레거시와 현대화된 시스템 모두 일시적으로 동일한 데이터베이스에서 작동

 

전술적 설계 의사결정 리팩터링

레거시 코드베이스를 현대화할 때 두 가지 미묘한 차이점을 알 필요가 있다.

1. 작은 점진적인 조치가 대규모 재작성보다 안전하다.
2. 도메인 모델로의 리팩터링이 한번에 이루어질 필요는 없다.

 

[결론]

이번 장에서는 실제 시나리오에서 도메인 주도 설계 도구를 활용하기 위한 다양한 기술을 배웠다.

다시 말해, 브라운필드 프로젝트와 레거시 코드베이스에서 작업할 때 반드시 DDD 전문가 팀과 함께 작업할 필요는 없다.

항상 비즈니스 도메인 분석부터 시작하여, 최고의 비즈니스 가치를 얻고자 노력하라.