왜 도메인 모델링을 하는가?
도메인 모델링 세미나 19
<도메인 모델링은 어떻게 하는가?> 편에서 다룬 내용은 글 한편으로 답할 수 없는 문제를 다뤘다. 화두를 던지고 연재를 통해 풀어갈 생각으로 쓴 글이다.
시점에 따라 달라지는 모델링 결과물
<도메인 모델링? 비즈니스 모델링 어떻게 하나요?> 편에서 인용한 그림을 보면, 시간의 흐름에 따라 모델이 결과물이 여러 개로 나타날 수 있음을 도식화했다. 당연한 이야기 같지만 훈련이 되지 않는 모델러들이 놓칠 수 있는 부분은 분명한 목적이 없이 분석하거나 표현하는 일이다.
보통 모델링은 분석이 필요한 대상을 대상으로 한 분석 결과인 경우가 많다. 그리고, 설계 가정이나 규칙을 담기도 한다. 무엇을 표현하려고 하는가? 모델러 스스로 분명하게 해야 한다. 그리고, 누구와의 소통에 사용할 것인가 따져 물어야 한다. 이에 대해 실전 상황을 배경으로 상세하게 설명한 내용이 바로 <도메인 모델링에서 맥락은 왜 필요한가?> 편이다.
도면은 설계가 아니다
<도메인 모델, Ongoing 설계 그리고 정원관리> 편에서 붙였던 단락 제목을 다시 차용한다. 당시에도 인용했던 Vaughn Vernon의 글귀 첫 문장을 우리말로 푼 것이다. 그의 다음 문장을 읽으면서 앞서 내가 설명한 내용을 풀어볼 수 있다.
도면(diagrams)으로 소통 내용을 담아둘 수 있다. <도메인 모델링은 어떻게 하는가?> 등에서 설명한 도메인 스토리텔링 도면을 만들어서 업무 담당자(domain expert)와 대화를 할 수 있다. 아니면 클래스도를 그려서 서 나 스스로 그리고 동료 개발자와 함께 볼 목적으로 발견한 규칙을 담아둘 수 있다.
의사결정을 돕는 모델링
최근에 내가 이사회 결과를 정리하면서 자연스럽게(혹은 습관으로) 그린 그림을 보자. 나는 함께 논의한 4 사람이 같은 생각을 하는지 확인할 의도로 '나는 이렇게 생각한다'라는 지식을 포착해 그림을 그린 것이다.
이렇게 하고 이를 전달하고 소통을 시도하면 다른 생각을 들을 수 있다. 그림만으로 소통이 될 수는 없지만, 의사소통을 돕는 것이다. 그리고 숫자는 우선순위인데 앞으로 여기에 입각해서 자원 투자나 업무의 진행 여부를 기준으로 삼겠다는 '결정을 전달'하는 의미이기도 하다. 결국 이는 이후에 벌어질 일상의 다양한 판단의 근거가 압축적으로 담긴 모델이다.
그림에서 오른쪽 글머리 기호와 함께 쓰인 목록은 각 자산별로 최우선 진행 업무를 요약했다. OKR 어휘를 빌면 이는 목표나 KR(핵심 결과)를 정의할 때 초점을 제공한다. 앞서 언급한 우선순위 숫자와 이들 항목의 조합으로 어떤 업무를 우선시할지 기준을 제시한다. 이를 근거로 삼으면 권한을 현장에 위임하는 일도 더 수월하다.
절차(프로세스)나 시나리오를 파악하는 모델링
아래는 동료가 그린 도메인 스토리텔링 그림이다. 이 그림 직전에 나는 동료에게 사용자(actor)를 유형으로 쓰지 말고 실명을 써보자고 제안했다. 다양한 공간에서 벌어지는 일이기 때문에 실제로 무슨 일이 벌어지는지 구체적인 예시가 되는 표현이 소통에 더 적합하기 때문이다.
이걸 토대로 동료는 현장에 가보고 담당자와 의사소통을 해서 실제로 어떤 일을 하고 어떤 고충이 있는지 파악하는 일을 하고 있다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
18. 도메인 모델링 절차에 대하여
