도메인 모델링은 어떻게 하는가?
도메인 모델링 세미나 16
이 질문을 지인인 이일민님이 지난 6월 말 실제로 했던 말이다. 하지만 당장 내 일은 아니기 때문에 정리된 답을 할 수는 없었다. 즉흥적으로 했던 답이나 그 후 생각한 내용을 글로 남기긴 했다. (아래 관련 글에 있다.) 그런데 이후 회사 동료가 꾸준히 도메인 모델링 연구를 하면서 질문을 던지고 있어 다시 이 질문을 소환해본다.
기획서만으로 개발할 수가 있나?
당시 일민형의 질문을 기억에 의존해서 살려내면, 일단 맥락이 Domain-driven design을 적용하고 싶어 하는 개발자들을 대상으로 했다. Domain-driven design을 적용한다는 말부터 엄밀하게 따지고 들 수 있지만, 여기서는 그저 복잡한 규칙을 가진 일상 업무용 응용 프로그램이라고 전제한다.
아래는 과거에 사용했던 화면 기획서 샘플이다. 보통 화면 기획서는 아래와 같은 내용을 정의한다.
화면 레이아웃과 사용자 이벤트, 필요한 데이터 요구
사용자 이벤트나 데이터 조회 과정에 적용할 규칙
기획서를 잘 쓰면 개발에 문제가 없다. 이론적으로는 그렇고, 운이 좋으면 실제로 그렇다. 문제는 기획자의 역량, 기획자와 개발자의 케미 등에 따라 실제로 그렇지 못한 경우가 발생한다. 그렇다면 어떤 보완책을 생각할 수 있을까?
화면 기획 말고 규칙은 개발자가 작성한다면?
종종 자신의 일상 업무에 익숙한 분들도 자신의 말로는 규칙을 이야기할 수 있지만, 개발자들이 원하는 형태로 표현하는데 익숙하지 않은 분들이 많다. 그래서 설명을 들어도 결국 개발자가 (결과 확인이나 시행착오 과정에서) 밝혀내는 경우도 다양하다.
또한, 기획서에 작성된 내용에 변경이 발생하면 코드에는 이미 반영되었기 때문에 기획서의 해당 내용까지 고쳐지는 경우는 매우 드물다. 그러한 점을 고려해서 개발자가 규칙에 대해 작성하기로 했다면, 도메인 스토리텔링에서 제안하는 방법이 유효할 수 있다.
출처: Domain Storytelling위 그림은 <도메인 스토리텔링은 무엇인가?> 편에서 소개한 <Domain Storytelling> 책의 1장에 도입부에 소개한 그림이다. domain expert는 우리말로 표현하면 업무 전문가라 할 수 있지만, (앞서 전제한 대로) 일상 업무용 응용 프로그램을 만드는 전제하에서는 해당 업무를 일정 기간 수행한 사람이라면 누구나 후보가 될 수 있다. 어차피 정리(그림에서 draws)하는 사람은 개발자(그림에서 developer)이기 때문에 꼭 '전문가'를 찾을 이유가 없다. 오류가 있더라도 다른 사람의 확인을 받으면 되고, 내가 프로그래밍할 수 있는 수준인지 판단을 내가 하기 때문에 훨씬 더 효과적인 방법이 될 수도 있다.
개발자가 규칙(비즈니스 로직)을 정리하면 생기는 이점
또한 개발자가 프로그램에서 요구되는 규칙을 정리하게 된다면 소통의 병목현상을 막을 수 있다. <아키텍처는 의사소통에 관한 문제라서?> 편에서 안티패턴의 상징으로 지휘자 이미지를 인용한 바 있다. 인용한 글에서 지휘자 이미지는 복잡한 로직을 담고 있는 코드를 말한 것이지만, 내가 <아키텍처는 의사소통에 관한 문제라서?>라는 제목으로 글을 쓴 이유는 프로그램뿐 아니라 규칙을 찾아내 정의하는 일 자체도 한 사람에게 의존하면 한 사람에게 부담을 주고, 그가 바쁘거나(부재중이면) 기다려야 하는 병목에도 똑같이 적용되기 때문이다.
반면 개발자가 직접 하게 되면 부담을 나눌 수 있고, 내가 필요한 내용을 직접 정리하는 이유로 필요한 만큼만 분석(대화)할 수 있어 효과적일 수 있다. 다만, 모든 개발자가 그렇게 할 수는 없으니 말 그대로 병목을 줄이는 수준으로 접근해야 할 듯하다.
도메인 스토리텔링의 강점
아직 <Domain Storytelling> 책을 다 읽은 것은 아니지만, 현재까지 파악한 강점은 분명했다. 직관적인 그림으로 표현할 수 있어서 표기법을 굳이 공부하지 않은 사람도 해당 업무만 알고 있으면 대화할 수 있다는 것이 가장 큰 장점이다. 그래서 구두 대화를 통해 구체적인 규칙을 끄집어내기 좋다.
또한, <모호함이 사라질 때까지 매개체를 풀어가기> 편에서 다뤘던 Work Object라는 개념이 매우 유용하다. 업무 진행 과정에서 정보의 사용과 변화를 위해 사용하는 매개체를 구체적으로 표현하고 소통할 수 있다. 아래 그림의 경우처럼 동일한 정보(상품정보)이지만 가격만 다루는 상황인지, 다른 정보를 수정하는 상황인지, 특정 형태의 목록을 다루는지 등을 구분해서 소통할 수 있다.
도메인 스토리텔링의 한계
다양한 이야기지만 도메인 스토리텔링이 설계의 모든 해법이 될 수는 없다. UI 설계에 사용할 수 있는 방법은 아니다. (유저 저니맵에도 어울리지 않는다.) 반면에 눈에 잘 드러나지 않는 업무 규칙과 시스템과 사용자의 상호작용 그리고 직접적으로 상호작용하지 않지만 서로 영향을 미치는 사용자 사이의 연관을 드러내는데 효과적이다.
또 한 가지 시스템 내부의 메커니즘 표현이나 객체 사이의 관계를 표현하는데 굳이 쓸 이유는 없다. 직관적인 그림 언어(Pictographic language)는 개발자가 아닌 일상 업무를 하는 사람들(domain expert)과 대화에는 유용하지만, 코드 작성에 직접적인 도움을 주지는 않는다. 당연하게도 시스템 내부의 작동 방식(mechanism) 표현에도 특별한 장점이 없다.
하지만, 이런 약점은 UML 표기법을 이용한 클래스도(class diagram)가 보완해줄 수 있어 둘을 잘 활용하면 좋은 방법이 될 수 있다.
도입을 하려고 한다면?
어떻게 시작할 수 있을까? eXper(XP를 하는 사람)로써 답을 하면, 나부터 시작하면 된다. 앞서 화면 기획 말고 규칙은 개발자가 작성한다면? 구절에서 설명한 대로 기본적으로는 개발자를 대상으로 하는 분석/정의 방법이다. 하지만, 그 개발자가 꼭 프로그램을 작성하는 사람이 아닐 수 있다. 우리 회사에서 도메인 모델링을 하는 동료는 프로그래머는 아니다. 하지만, 프로그래밍 언어에 대한 지식이 없을 뿐 프로그램의 작동 방식을 개발자와 이야기할 수 있고, 시스템 개발에 참여한다는 점에서는 개발자로 분류할 수 있다.
관련 글
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
10. Repository 빌딩 블록에 대해 생각해보기
11. 맥락은 어떻게 표현할 것인가?
