시스템 릴리즈와 아키텍처의 관계
도메인 스토리텔링 연구 No. 17
<도메인 스토리와 개인 업무의 이중 구조>편에서 언급한대로 동료들과 협업하면서 다시 상태도를 그려야 하나 싶었다. 그러나 설계서는 의사소통에 초점을 맞춰서 결정하고 드러내고 사용해야 한다. 그래서 (상태도 대신에) 지금 이 순간 가장 필요한 그림을 그렸다.
협업의 경계를 드러내는 그림
개발팀 운영과 릴리즈 속도를 고려해서 개발조직을 나눠야 한다고 판단했다. 소위 말하는 MSA 도입이 필요한 상황이다. 이를 위해 여러 가지 요소를 고려한 후에 곧 있을 회의를 앞두고 머릿속 생각의 아웃라인을 그린 그림을 그렸다. 아래 그림과 비슷한 형태의 3장의 그림을 그렸다.
위 그림을 부르는 (매장) 접수기 개념 설계이고, 특정 유형의 표기법을 따르지 않았다. 결국 그림은 소통을 위한 것이고 보자마자 참여자 다수가 궁금해하는 부분을 한 장에 담아내기 위한 그림이다.
도메인 스토리와 내가 그린 그림의 역할
문득 그동안 동료가 열심히 그려온 도메인 스토리와 내가 그린 그림이 무슨 관계일까 생각해보았다. 나는 도메인 스토리로 풀지 못하는 부분이 있다고 판단하고 그렸다. 그게 뭘까? 우리가 만들려고 하는 목표 시스템(상상일 때도 있고 실제 구현한 것의 수정일 수도 있다)의 골격에 대한 그림을 그렸다. 내가 아는 표현 중에 가장 가깝다 느끼는 말이 아키텍처다. 결국 3장의 그림은 당장 필요하다 느끼는 아키텍처 뷰(아키텍처를 드러내는 그림)이다.
반면 동료가 그린 수 많은 그림은 시스템을 둘러싸고 벌어지는 다양한 쓰임새를 상세하게 묘사한다. 위에 내가 그린 그림에서 구의 표면에서 벌어지는 일에 대한 묘사이고, 핑크색 점이 도메인 스토리를 추상화 한 그림이다.
덧붙여 최근 Vaughn Vernon의 링크드인 글에 소개된 Impact Map Template 에서 스토리의 위치를 보면 그 의미가 분명해진다.
아키텍처와 시스템 릴리즈
매번 시스템 릴리즈마다 아키텍처가 바뀔 수는 없다. 그렇다고 아키텍처를 바꾸지 않고 기능만 추가하면 흔히 말하는 기술 부채 문제에 부딪힌다. 릴리즈와 아키텍처는 비유하면 대각선처럼 상호 교차하는 관점이다. 이를 적절히 풀어내는 것은 매우 중요하다.
나는 곧 있을 릴리즈 목표를 위해 3장의 그림을 그렸는데, 앞서 제시한 그림과 또 하나의 그림은 각각 서로 다른 현장과 연결된다. 더불어 BoundedContext라고 부를 수도 있다. 다시 말해 하나의 BoundedContext 마다 하나의 그림을 그렸다.
그리고 하나의 그림을 더 그렸는데, 이전에 상태도로 표현하려던 의도를 담았다. 상태변화에 따라 개발자들이 각각 다른 일을 해야 하는 상황을 소통할 필요를 느꼈다. 그래서 전형적인 상태도를 그리는 대신에 아래와 같이 상태 변화에 따라 영향을 받는 프로그램 단면(혹은 인터페이스)을 기호로 표기했다.
또한 스윔레인으로 구분하여 기부자의 사용자 여정을 상태 변화 윗쪽에 배열하고, 아래에는 업무 프로세스가 놓여지게 했다. UX 전문가와 운영자, 기획자와의 소통을 고려한 선택이다. 거듭 말하지만 설계서의 가치는 의사소통에 있다.
지난 도메인 스토리텔링 연구
3. 도메인이 무엇인가요?
14. 도메인 스토리의 적절한 구도
