Database Driven Development에서 진짜 DDD로의 선회, 이벤트 스토밍 -2-
DDD를 위한 첫걸음. Event Storming
황건구
게시 날짜: 2020.05.22.
들어가며
이번 편은 지난 글에 이어 이벤트 스토밍의 경험에 대해 세부적으로 다루고자 합니다.
학창 시절의 우리는 시험 문제를 풀기 위해서 우선 문제를 읽고 이해해야 했습니다. 이와 같이 어떤 문제나 과정을 프로그램의 영역으로 가져오기 위해서는 그것(문제)을 올바르게 이해하는 과정이 선행되어야 합니다.
이론 물리학자 리처드 파인만은 생전에 이런 말을 했습니다.
우선은 자신이 "이해하고 있는 것"이 무엇인지 알아야 하고, 이해하고 "새로 알게 된 것"은 받아들일 수 있어야 하며, 반대로 "무엇을 이해하지 못했는지" 인정해야 한다.
우리는 해결코자 하는 것인 "문제"가 무엇인지 제대로 이해해야 합니다. (문제와 요구사항은 다릅니다.)
문제를 더 잘 이해하기 위해서는 각자의 머릿속에 현실을 도식화할 필요가 있습니다. 그리고 이벤트 스토밍은 불확실한 대상을 집단이 함께 파악해 나가기에 좋은 도구입니다.
이벤트 스토밍은 도메인에서 발생할 수 있는 여러 이벤트를 쉽게 식별하기 좋은 워크샵 형태의 방법론입니다. 단순하게 DDD만을 위한, 개발자를 위한 도구가 아닌, 그냥 여러 가지 문제 식별과 해결에 좋은 도구입니다. 다른 용도로도 얼마든지 쓸 수 있습니다!
일단은, 이벤트 스토밍을 하는 방법
방법만 열거하면 경험이 없는 사람들의 흥미를 끌어내긴 어렵지만, 이해를 돕기 위해 일반적인 과정을 열거해 봤습니다. 가급적 모든 스테이크 홀더들(도메인 전문가(실무자), 기획자, 개발자, 디자이너 등)이 한 장소에 모여서 시작합니다.
여러 색상의 포스트잇을 이용해서 개념을 그려내는 과정을 진행하는데 다음과 같은 대상들을 순차적으로 식별합니다.
색색의 포스트잇과 화이트보드를 이용하는 것이 좋지만, 물리적인 한계가 불편하다면 Miro를 사용하는 것을 추천합니다. 상세한 과정과 설계에 대한 방법은 K-MOOC의 온라인 강의와 IBM developer 포스트 등을 보시는 것을 강력히 추천합니다. 아래 내용은 간략한 설명입니다. (가급적이면 도메인 이벤트부터 ~ 애그리게잇 식별까지는 순서대로 하시기를 권합니다.)
도메인 이벤트 (주황색)
- 괄호 안은 포스트잇 메모지 색상을 의미합니다.
비즈니스 프로세스에서 유발되는 이벤트. 과거형 동사로 작성하며, 시간 흐름 순서대로 왼쪽에서 오른쪽으로 진행하듯 붙입니다.
커맨드 (파란색)
애그리게잇에 속한 뷰를 통해 액터가 도메인 이벤트를 유발하고, 그 결과로 도메인 이벤트가 유발됩니다. 도메인 이벤트 좌측에 붙여 줍니다.
애그리게잇(노란색)
커맨드가 실행되고 이벤트가 벌어지는 것을 무엇이라고 칭할 수 있는지를 애그리게잇으로 표현. 좀 더 현실 세계로 생각해 보자면 어떠한 행위에 대한 문서(또는 보고서)와 흡사한 것입니다. (예를 들자면, 주문서, 송장 같은 것이 있습니다.) 커맨드, 도메인 이벤트를 포함토록 상단에 붙여 줍니다. (이로써 커맨드와 도메인 이벤트가 시각적으로 애그리게잇에 포함되게 되었습니다.)
액터(작은 노란색)
뷰를 통해 들어와 커맨드를 유발할 수 있는 사용자(역할). 커맨드 옆에 작게 액터를 표시해서 붙입니다.
뷰(초록색)
사용자가 시스템과 상호작용 할 수 있는 화면으로 세세하기보다는 컨셉에 대한 이해를 돕기 위한 보조 수단으로 커맨드 좌측에 붙여 줍니다.
비즈니스 프로세스(보라색)
비즈니스 규칙에 따른 복잡한 절차. 최소 하나 이상의 도메인 이벤트를 유발합니다. 독립적으로 존재하며 도메인 이벤트와 동일한 방법으로 좌측에서 우측으로 전개해 나갑니다. (진행되다 보면 여러 도메인 이벤트와 외부 시스템 등으로 분할 식별 될 가능성이 있습니다.)
외부 시스템 (핫 핑크)
서드 파티 서비스와 같이 외부에서 제공해주는 것. (가령, PG사 연동) 우리가 API를 호출하거나 음식을 주문할 때처럼 단순히 외부 시스템은 이벤트를 수용하거나 이벤트를 유발하는 정도의 동작을 하게 됩니다. 비즈니스 프로세스와 마찬가지로 좌측에서 우측으로 흐름에 따라 전개해 줍니다.
이슈(빨간색)
모호한 것들. 의사 결정이 필요한 것들. 무엇이든 애매한 것은 그 즉시 이것으로 표시해 붙입니다.
아무튼, 이벤트 스토밍 시 주의사항
이벤트 스토밍은 본질적으로는 브레인스토밍에 도구와 몇 가지 규칙을 더한 것에 불과합니다. 따라서 방법만 보면 단순해 보이지만 자유도가 높은 만큼 처음 시도할 때 사람들은 또 고민에 휩싸이게 됩니다. 그렇기에 평소 브레인스토밍이 어렵게 느껴지신다면 같은 어려움을 겪으실 겁니다.
틀리면 안 된다는 부담은 잠시 잊으시길 바랍니다.
이벤트 스토밍을 하기 위해 포스트잇을 쓰는 이유는 단 하나입니다.
디자인이 원래 한 번에 되는 게 아니기 때문입니다.
(이벤트 스토밍을 직접 시작하시면 아주 여러 번 붙였다 떼었다, 색상을 바꿨다가 이름을 바꿨다 하게 되실 것입니다.)
잠깐 이 이야기의 시작인 DDD로 돌아가서, DDD의 모델의 정합성에 대한 그림(아래 참조)을 보시면, 그림 속 제일 위에 "지속적 통합(Continous Integration)" 이란 표현이 있습니다.
지속적인 통합이란 표현 자체가 "변경"이 있음을 암시합니다. 디자인의 지속적인 변경과 미세한 조정은 프로세스의 일부로 받아들이고 시작해야 합니다.
미심쩍어하실 완벽주의자들(또는 실천하지 않는 사람들)을 위해 한가지 증거를 보여 드리겠습니다.
미켈란젤로의 시스티나 성당의 그림의 스케치입니다. 위대한 예술가마저도 다양한 아이디어와 실험을 거듭한 끝에 그림의 "한 부분"을 확정 지었습니다.
..
실제 저 그림이 차지하는 부분은 전체의 일부였습니다.
마찬가지로 시스템을 디자인하거나 구현하는 것 역시 한 붓 그리기처럼 단번에 확정 짓는 것을 의미하지 않습니다.
이벤트 스토밍은 브레인 스토밍과 같이 일단 시작하는 것이 중요합니다.
(잘못된 아이디어나 개념이나 단어들이 등장해서 체면을 구기는 것을 두려워해서는 안됩니다.)
처음에 이상한 표현과 어색한 그림이 그려지는 것이 결과적으로 더 바람직한 그림을 그리는 데 있어서 매우 중요한 기초가 됩니다. 우리가 도메인에 대해서 논할 때 오해가 발생하고 혼란을 느끼고 순서를 헷갈리는 것은 그럴 만한 이유가 있기 때문입니다.
우린 그 부분을 온전히 이해해 내거나 더 단순한 문제로 만들어 내야 합니다.
그러니 누군가 나서서 기꺼이 틀려야 합니다.
그런데, 실제로 하면 어려운 것들
참여의 문제
이벤트 스토밍은 앞서 언급했던 것처럼 부담 또는 의심으로 인한 "적극적인 참여가 안되는 상황"이 제일 큰 문제로 작용합니다. 누군가는 너무 기초적인 질문이나 표현 등으로 인한 체면의 문제가 있을 것입니다. 또는 이미 해박한 수준의 도메인 지식이 있는 참여자의 경우에는 당연한 이야기들이 오고감으로 인한 시간 낭비라고 여기는 문제도 있을 겁니다. 전자는 팔짱을 끼고 듣기만 하는 청취자의 모습으로, 후자는 일방적으로 내용을 전달하는 진행자의 모습으로 이벤트 스토밍의 취지가 변질 될 겁니다. 이벤트 스토밍은 역할이나 본인의 지식수준에 매몰되는 일이 없어야 합니다.
(팔짱을 풀어주세요.)
취약한 기존 구조의 문제
그리고 모든 과정에 모두가 적극적으로 참여하여 잘 진행되어도 결국에는 난관에 봉착하게 됩니다.
대부분의 비즈니스에는 임기응변에 의존해왔던 것들이 제법 존재하기 때문입니다.
(작동은 하는 비즈니스의 예)
그곳에 도달했다는 경험적인 증거는 다음과 같습니다.
- 이거, 저거, 그거와 같은 모호한 표현이 등장합니다.
- 경계선에 아주 가깝거나 이쪽과 저쪽의 경계선을 왔다 갔다 하는 것이 생겨납니다.
- 하나의 무언가인 줄 알았는데 이야기할 때마다 대상을 더 나눌 수 있게 되거나 이름이 바뀌게 됩니다.
이벤트 스토밍은 그 과정 중에 이렇게 그동안 체계화되어있지 않았던 영역이 어디인지 직관적으로 알아낼 수 있고 그 부분을 외면하는 대신 보다 적극적인 논의를 통해 구체화해야 합니다.
2편의 마무리
이벤트 스토밍은 여러분들이 앞으로 DDD를 실천 하는 데 있어서 시도하실(해야만 하는) 수많은 수단과 방법 중에서도 첫 단추에 불과합니다.
이 시도가 의미 있게 느껴지기 위해서는 그만큼 여러분들이 얼마나 열성적으로 탐험 과정에 임했느냐에 따라 달라지게 됩니다. 도메인 용어, 범위, 현재와 미래에 대한 끈질긴 호기심과 탐험은 만들고자 하는 시스템을 구성할 훌륭한 블록들이 될 겁니다.
DDD를 하기 위한 여러 가지 수단과 방법을 의심하거나 주저하는 대신 그 과정에 하나씩 몰입해 보시기를 강력하게 권합니다. 다음번에는 몹 프로그래밍을 실천하던 과정 중에 유용했던 도구와 지켜야 하는 규칙 등에 대해서 다뤄 볼 예정입니다.
함께 읽기
- Database Driven Development에서 진짜 DDD로의 선회 -1-
- Database Driven Development에서 진짜 DDD로의 선회, 이벤트 스토밍 -2-