도메인 스토리텔링 응용 2
<스토리텔링 문법을 개발하라>편에서 소개한 두레이 업무로 나는 3가지 질문을 올렸다. 동료 스토리텔러는 그 중에 3번째 질문에 먼저 답했다. 협업할 때 중요한 점은 가급적 개취를 인정해주는 것이다. 당장 급한 일이나 중요도 높은 일이 아니라면 궁금함과 풀어보고 싶은 욕망의 순서를 존중해줘야 한다.
동료가 잘한 점은 질문을 다시 한 것이라 생각한다. 다른 사람의 질문을 그대로 받아 문제로 삼기 보다는 소화하고 내가 풀어볼 질문으로 바꾸는 일은 몰입도를 높여 일을 즐겁게 한다.
나는 지불하다 라는 표현의 정규화에 초점을 맞추자 제안했안 동료는 소비자의 결제처 혹은 그에 대한 인식이 모호한 점을 풀려고 있다. 나는 이 짧은 협업만으로도 문법을 정의하는 행위가 결국 직관적으로 이해하기 위한 방법을 찾는 노력이라는 점을 깨달았다.
도메인 스토리텔러 자신의 질문으로 인해 그의 작업은 다음과 같이 이어지고 뒤이어 도메인 스토리도 앞서와는 다른 그림으로 펼쳐진다.
두레이 댓글로 처음 위 내용을 보았을 때는 의도를 알 수 없었다. 그래서 비대면 대화가 이어졌고, 지금은 동료의 의도를 이해했다.
도메인 스토리텔링의 멋진 점은 표기법의 직관성과 Icon을 이용한 표현력으로 인해 다양한 유형의 이해관계자와 소통이 가능하고, 자연스럽게 피드백 수집에 유리하다. 과거 UML이 Executable 즉, 구현 자체를 밀접하게 표현하는 방향으로 발전하시면서 역할이 줄어든 방향과 달리 도메인 스토리텔링은 의사소통을 도울 수 있다. (그리고 그 방향으로 우리가 발전시킬 생각이다.)