DDD로 워크샾하는거죠?

MSA도입시 제일 먼저 맞닥뜨리는 문제가 서비스를 어떻게 쪼갤것인지, 즉 어떻게 식별하고 정의할것인가에 관한 문제다. 그 방법은 다양하지만 제일 먼저 고려되는것이, 많이 들어본 방법이, 유행하는듯한 기법이 워크샾을 통해 뭔가 할 수 있을것 같다는 것이다. 그리고 어디선가 DDD로 그렇게 할 수 있다는 이야기를 들은것 같다. MSA를 하려면 DDD를 해야한다는 말도 함께.

 

DDD를 처음 주장한 에릭 에반스는 도메인 전문가를 포함한 DDD개발팀과 주로 화이트보드에 Class Diagram을 그리며 의사소통했다고한다. 너무 얽매이지 않았지만 그래도 기본적인 UML표기법에 따랐을것이고 어느정도 시간이 지나고 자주 보다보면 의사소통하는데 문제 없다는 듯 이야기하고 있다. 하지만 과연 그랬을까 하는 의문이 들었고, 특히나 우리나라의 현실에서도 통할까 싶었다.

 

그리고 반버논은 이렇게 이야기했다.

... 나는 이벤트 주도 모델링이라고 부르는 기술을 사용했다. 그것은 보통 대화, 시나리오 구체화, 매우 경량화한 UML을 사용한 이벤트 중심 모델링과 연관이 있다. UML로 구체화하는 과정은 화이트보드만을 사용할 수도 있고, 도구를 사용해 그려낼 수도 있다. 하지만 UML을 아주 조금이라도 능숙하고 이해하고 사용할 수 있는 비즈니스 측 사람은 거의 없다. 따라서 대부분은 모델링 영역의 몫으로 남아서 UML의 기본을 이해하고 있는 개발자나 혹은 내가(또는 모델러) 수행해야 했다. 이는 매우 유용한 방법이긴 했지만, 이 과정에 비즈니스 전문가를 좀 더 직접적으로 참여시킬 방법이 필요했다. 이는 UML이 아닌 좀 더 참여를 유도할 수 있는 다른 도구가 필요하다는 것을 의미했다.

나는 몇 년 전, 다른 형태의 이벤트 주도 모델링을 경험했던 알베르토 브란돌리니로부터 처음 이벤트 스토밍에 대해 배웠다. 언젠가 시간이 별로 없었을 때, 알베르토는 UML 대신 포스트잇을 사용하기로 결정했다. 이것이 회의실 안의 모든 사람이 프로세스에 직접 참여해서 빠르게 학습하고 소프트웨어를 설계하는 방법의 시초였다.

- Domain-Driven Design Distilled by Vaughn Vernon, 7장 가속화 관리 도구 (p169 ~ 170)

Event Storming(ES) 은 위와 같은 이유로 알베르토에 의해 발명되었고 수많은 장점이 있다. https://en.wikipedia.org/wiki/Event_storming 

 

 

ES를 발명한 알베르토가 직접 운영하고 지금도 활발히 활동하는 내역까지 공개하는 사이트이다.

https://www.eventstorming.com/

EventStorming

위의 ES가 정말 훌륭한 방법임에는 틀림없지만 그럼에도 제가 보기에는, 한국의 현실에 적용하기에는 어려움이 있어보인다.

• 위의 위키나 ES 사이트 또는 수많은 유투브 동영상을 보면 나와 있듯이
  Domain event, Actor, Business process, Command, Aggregate, External system, View 등 다양한 색깔의 Notation과 절차가 있다. 하지만 현업이 중심이 되어 진행하는 ES에서 이 수많은 개념과 Notation을 설명하고 진행하면서 업무지식까지 끌어낼 수 있겠는가? (예 : Aggregate, 반버논의 책에서도 나온다. 미국 사람들도 이해 못하는 경우 Aggregate가 아닌 그냥 Data 정도로 표현한다고 한다)
• UML을 이해하기 어려워하는 도메인 전문가의 참여를 이끌어 내기에는 위의 Notation과 절차도 너무 복잡하다. 중요한것은 Event이다. 나머지는 부수적인 것이고 위와 같이 한번에 표현할 필요가 없다.
• 그리고 DDD의 전략설계(Bounded Context 등)와 전술설계(Aggregate 등) 개념을 한꺼번에 표현하려는 것도 이해하는데 큰 방해 요소다.
• Context Mapping 도 Bounded Context(BC) 간의 큰 흐름만 그것도 한방향에 대해서만 표현한다. 개별적인 API/Publisher/Subscriber 등을 표현해야 API First Design 에 충실할 수 있지 않을까?
• 전술설계에 해당하는 Layered Architecture, Aggregate, Entity, Value Object, Repository 등 BC내의 컴포넌트까지 ES에서 모두 표현하니 너무 어렵지 않은가?
• DDD의 전략설계 : Sub/Core Domain > Bounded Context > Context Mapping 을 잘 표현할 수 있는 방법이 없을까?
• Notation을 최소화하고 간단한 설명과 절차로 해당 Domain Event와 업무에 충실하게 집중할 수 있는 방법은 없을까?

위의 단점을 극복할 다른 워크샾 방법이 있다. 특별한 이름은 없지만 '서비스 정의 워크샾' 정도로 부르겠다. 이에 대해서는 별로로 설명할 기회를 갖겠다. 중요한 것은 서비스를 '식별' > '검증' > '정의' 하는 단계를 거치면서 참여자들이 합의할 수 있어야 하고, 어렵지 않아야 하며, 자연스럽게 기본설계 즉, API First Design 을 연결되어 Provider/Consumer 입장의 Contract 를 정의할 수 있어야한다.