DDD, Event Storming

Domain-Driven-Design 

실제 코드로 구현 가능한 현실성 있는 도메인 모델 분석과 그것을 추상화하는 설계

도멩니 모델의 적용 범위를 구현까지 확장하여 도메인 지식을 구현 코드에 반영한다.

 

도메인이란 ?

소프트웨어로 해결하고자 하는 문제 영역

예를 들어, 이커머스의 도메인 = 온라인 상의 제품 판매

 

DDD는 개발자와 이해관계자(Stakegholder)의 적극적인 커뮤니케이션 태도가 필요하다.

 

DDD 도입 하여 하나의 기능을 개발하기 위해 즉, 문제에 대한 해결책을 찾기 위해 엄청난 비용이 발생한다.

 

Event Storming

알베르토 브란돌리니가 제안한 복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 워크숍

클래스와 데이터베이스가 아닌 이벤트와 비즈니스 프로세스에 중점을 두며 코드를 없애 개발자 뿐만 아니라 

도메인 전문가와 함께 도메인 지식을 학습할 수 있게 설계함

 

준비물

회의실, 큰 종이, 포스트잇과 마커펜 등을 구비해둔다.

실제 문제 해결에 관련된 모든 사람이 참여해야한다.

진행이 원활이 이루어 지도록 퍼실리테이터가 필요하다.

 

진행 방식

종이 위 포스트잇을 붙여나간다.

모든 사람의 생각을 허용하고 존중한다.

비즈니스 프로세스를 이해하는 데에 초점을 맞춘다.

 

이벤트 스토밍의 가치

커뮤니케이션

 

이벤트 스토밍의 핵심원칙

모든 참가자의 참여를 극대화 하는 것이다.

포스트잇을 사용하는 이유는 모든 사람이 적극적으로 참여하고 이동과 수정이 편리하여 참여자의 부담을 덜어준다.

 

1단계 : 혼란스러운 탐험

- 각자가 알고 있는 도메인 이벤트 작성 (토론 없이 자신의 방식으로 기록)

평균적으로 2시간의 워크숍에서 100 ~ 200개 정도의 도메인 이벤트가 발생한다. 

 

도메인 이벤트 (주황색)

도메인 전문가가 관심이 있는 어떤 사건으로 보통 "~ 할 때", "~ 발생하면", "만약 ~하면"과 같은 요구사항

이벤트 이름은 과거 시제를 사용한다.

이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다.

 

2단계 : 타임라인 적용

- 모든 도메인 이벤트를 올바른 타임라인으로 정렬 후 중복되는 이벤트를 제거한다.

주의할 점은 동일한 용어지만 다른 개념일 수 있으므로 확실한 중복만 제거한다.

시간은 왼쪽에서 오른쪽, 수직 방향으로 평행한 시간을 표현할 수 있다. 

발생한 갈등을 시각화하고 캡쳐하는 데 사용

 

핫 스폿 (자주색)

2단계에서 발생한 갈등을 시각화하고 캡쳐하는 데 사용하며 문제가 해결되면 제거

 

액터(노란색)와 시스템(분홍색)

구체적인 페르소나를 결정한다.

외부 시스템부터 일부 레거시 및 마이크로서비스에 이르기까지 책임을 전가할 수 있는 모든것을 설정한다.

 

커맨드(파란색)

시스템에서 일어나는 일로 도메인 이벤트가 발생하는 원인이다.

 

리드 모델 (초록색)

결정을 내리는데 필요한 정보로 예를 들어 수강신청의 경우 강의 이름, 기관, 모집 상태 등이 액터에 도움이되는 정보이다.

 

정책 (연보라색)

"~할 때마다"라는 단어로 시작하는 것으로 도메인 이벤트와 커맨드 사이에 위치한다. 예를 들어 수강생이 등록될 때마다 수강신청 성공메일을 보내는 정책 등 이다.

 

애그리게잇 (연노란색)

내부 시스템이 기대하는 책임을 수행하며 트랜잭션 일관성을 유지하는 단위이다. 불변식이 깨져서는 안되면 실제로 주어진 클래스들의 계약을 정의하는 방법이며 구현은 자유롭게 할 수 있다. 비즈니스 규칙라고도 한다.

 

 

참고자료