DDD 이벤트 스토밍 후기

DDD?

DDD(Domain Driven Design)는 약자 그대로, 도메인 주도 설계로 아키텍처적인 얘기를 하는 것으로 보인다. 본인도 DDD는 아키텍처중에 하나 아닌가? 하는 생각이 들었다.

 

하지만, 수강한 DDD 강의에서는 DDD를 아키텍처로 보기보다는, 일을 편하게 하기 위한 방법 또는 같이 일하는 이해관계자들과의 동일한 의사소통 설계로 설명을 한다. 처음에는 이해가 되지 않았지만, 이벤트 스토밍을 겪어보니 일을 잘하는 방식과 닮아있었다.

 

간단 용어

 

• 사용자: 애플리케이션을 사용하는 불특정 다수로, 요구 사항을 가지고 있음.
• 도메인 전문가: 소프트웨어 개발이 아닌 업무 도메인에 전문 지식이 있는 사람으로, 용어나 구조의 부정확성을 지적해야 함.
• 개발자: 소프트웨어를 개발하는 사람으로, 기능과 시스템 설계를 다루지만 도메인 지식은 부족할 수 있음.
• 도메인 이벤트 : 상태가 변경되는 사건으로 '~하면 ~가 발생'등으로 표현.

 

 

진행 방법

사용자, 도메인 전문가, 개발자로 역할군이 나뉘며, 도메인 이벤트의 발생에 따라 시간순서로 왼쪽에서 오른쪽으로 진행한다. 커다란 진행 틀은 아래와 같다.

 

1. 도메인 이벤트들을 참여자들 모두가 포스트잇에 적어 벽에 붙인다.

2. 모르거나 애매한 내용은 도메인 전문가에게 묻는다.

3. 휴식 후, 중복이나 공통된 부분은 상의해서 제거하고 비즈니스 프로세스에 초점을 두고 재배치한다.

 

1번, 2번 과정을 사진으로 담지는 못했지만, 우리조가 진행했던 비즈니스 프로세스이다.

도메인 상태에만 집중하였기에 간소화 되었다..

 

• 1번~3번의 Before-After가 잘 정리된 옆 조의 이벤트 스토밍 사진.

 

 

후기

게시글에서는 나머지 용어나, 세세한 진행방식에 대해서는 기입하지는 않았지만 확실히 '회사에서 적용해보면 좋겠다' 라는 생각을 들게하는 의사소통 방식이였다. 비즈니스 프로세스 자체가 개발자만 고민하고 얘기하는것이 아닌 모두가 동일한 언어(유비쿼터스)로 소통하고 고민하는 과정이며, 실 업무에서 느낄 수 있는 개발자와 타 이해관계자와의 벽을 조금이나마 허물어 줄 수 있을 것으로 보인다. (물론 실제로 도입하고 용어를 통일하는 것은 많은 노력이 있어야 할 것 같다.)

 

DDD 이벤트 스토밍에 대해 설명해주시는 제이슨님.

DDD 강의나 이벤트 스토밍 모두 좋은 경험이였고, 다른 개발자분들과의 소통도 꽤나 흥미로웠다.