실전 도메인 스토리텔링 첫 시도
도메인 스토리텔링 연구
링크드인에서 DDD 관련 외국 엔지니어들과 친구관계를 맺고 있어 알게된 Domain Storytelling 도구를 시험삼아 써봤더니 효과가 있었다.
ㄹ물류 시스템 현황 파악용도로 써보기
관계사에서 IT 시스템을 다루는 실무자들과 첫 미팅에서 바로 도구를 써서 상황을 도식화하고, 질문을 하고 내용을 반영하며 소통의 도구로 사용해보았다. 1시간 남짓 시간만에 맥락을 파악하고 서로 공감하는 하나의 그림을 만들 수 있었다.
아래 그림인데, 과거 UML을 그리던 시절에 맥락도(Context Diagram)를 그리는 것과 유사하다.
다만, 표준화된 표기법을 중시했던 UML과 달리 도메인 스토리텔링은 업무 전문가와 개발팀의 소통을 도와 (특정 도메인) 업무 지식을 소프트웨어 개발에 필요한 형태로 변환하는데 목적을 둔다.
Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams
그런 점에서 꽤 성공적인 첫 경험을 했다고 판단하는 이유는 아래와 같다.
두 사람 모두에게 표기법에 대한 설명을 할 필요가 없었다.
그림을 보면서 두 사람이 적절하게 (내가 들어야 할) 이야기를 꺼냈다.
도메인 지식 변환하기
효용성을 입증하기 위해서는 아래 문장이 요구하는 행동의 결과를 만들어내야 한다.
transform domain knowledge into effective business software
해보자. 먼저, 도구적 제약에 갇히지 않기 위해 그림을 그대로 가져다가 원하는 정보로 분해와 분류를 해보기로 한다.
사용자(Actor) 맥락부터 점검
뭐부터 할까 하다가 사용자부터 관점을 분류하기로 했다. 그랬더니 inbound와 outbound를 구분하지 않은 역할도 사람이나 회사가 겸업을 해서 그렇지 역할은 inbound와 outbound를 겸한다는 점을 알 수 있었다. 참고로 해당 물류 업무는 과거 무역업에 해당하는 Cross Border 물류이다. 그래서, 특정 국가를 기준으로 나가는 것을 outbound, 들어오는 것을 inbound라고 지칭한다.
그러면 모든 역할에 있어 공통으로 In/out-bound 로 구분할 수 있다는 사실을 확인한다. 조금 더 정교하게 말하면, 상품이 출발하는 지역과 상품이 도착해야 하는 지역이 있으니 조합으로 개수가 발생한다.
핵심 엔티티 정의
논리적 완결성을 위해서는 맥락을 국가 대응짝 별로 세분화해야 하는지 당사자들이 부르기 좋아하는 In/Out-bound 관행을 유지하면서 추가 정보를 넣어야 하는지 고민하다가 탈출구(?)가 떠오른다. 접수내역이라고 부르는 기초 정보가 이를 포함한다고 개념을 잡으면 단순해진다. (단순성은 소프트웨어 개발에서 중요한 가치다.)
작명은 이후에 다듬기로 하고 방금 고안한 개념을 부르는 말로 CrossBorder Transaction 을 쓰기로 한다. 그리고, 필수 속성으로 앞서 고민했던 출발 국가와 도착 국가를 나타내는 짧은 단어 from, to를 정의한다.
원형(Archetype) 정의하기
엔티티를 구성하는 실제 값이 어떤지 예시를 들어보고 그걸 토대로 필수 구조인 원형(archetype)을 정의해본다.
Transaction를 거래성격의 엔티티로 보면 거래 주체를 노드로 하는 하나의 선 혹은 그래프 형태로 엔티티를 표현할 수 있다. 이를 데이터베이스에 저장하려면 노드 구성 정보와 함께 현재 상태를 나타내는 값을 CrossBorder Transaction이 관리해야 함을 알 수 있다.
상태 변경을 업무 이벤트로 포착하기
이후에는 정보를 다루는 방식의 선호나 선택이 개입될 수 있는 지점이다. 과거에 흔히 쓰던 방식으로 DFD(Data Flow Diagram)가 있다. 데이터가 입력-처리-출력(IPO) 과정으로 일련의 변경 작업으로 가정하는 방식이다. 이는 데이터가 물리적으로 한 곳에 있는 경우 유용하지만 분산 환경에서는 중복이나 통신 부하를 유발한다.
우리(베터코드)는 분산 환경을 전제로 시스템을 구현하기 때문에 느슨한 시스템 연결을 가능하게 하는 도메인 이벤트를 채용한다. 이를 CrossBorder Transaction Event 줄여서 CBT Event라고 정의하면, 상태 변경에 따라 달라져야 하는 내용을 정의해야 한다. 거래(Transaction)를 구성하는 노드가 되는 주체가 해야 하는 행동 혹은 확인해야 하는 정보가 그것이다.
