동작하는 도메인 모델 만들기
모든 소프트웨어 프로그램은 도메인을 갖고 있다. 여기서 도메인이랑 사용자가 해당 프로그램을 사용하는 영역을 말한다.
이때 도메인은 물질적으로 존재할 수도 있고 그렇지 않을 수도 있다.
예를 들어, 항공 예매 프로그램의 도메인 중에는 실제 탑승하는 승객들이 있을 것이다.
반면 회계 프로그램의 경우엔 금용과 같은 비물질적인 것도 있다.
그렇다면 도메인 모델은 무엇일까.
사용자의 활동에 도움이 되는 소프트웨어를 만들기 위해서 개발팀은 사용자의 활동과 관련된 지식 체계에 집중해야 한다.
다시 말해 엄청난 양의 도메인 지식을 익혀야 한다는 것의 의미한다.
모델은 이러한 양과 복잡성에 대한 부담을 어느정도 해소하기 위한 도구이다.
모델은 선택적으로 단순화하고 의식적으로 구조화한 형태이다. 적합한 모델이라면 정보를 이해하고 문제 자체에 집중할 수 있도록 만들어줄 것이다.
이러한 측면에서 영화 제작과 유사하다고도 볼 수 있다.
영화는 현실의 이야기를 다루지만 모든 장면을 담지는 않는다.
선택과 집중을 통해 감독이 하고 싶은 이야기와 논지를 펼쳐나간다. 마치 세상을 어떠한 창문을 통해 보는 것 처럼.
도메인 모델러 또한 단순히 사실적인 모델을 만드는 것이 아니라, 현실 세계에 실재하는 사물에 대해 그 목적에 맞는 도메인 모델을 선택하는 것이다.
도메인 주도 설계에서의 모델의 유용성
도메인 주도 설계에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다.
-
모델과 핵심 설계는 서로 영향을 주며 구체화된다.
모델을 의미 있게 만들고 모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장하는 것은 다름아닌 모델과 구현 간의 긴밀한 연결이다. 이러한 특성은 유지보수와 기능 개선에도 도움이 되는데 그 이유는 모델을 이해하는 바에 근거해 코드를 해석할 수 있기 때문이다.
-
모델이 모든 팀 구성원이 사용하는 언어의 중추다.
개발자와 도메인 전문가는 이 언어를 토대로 프로그램에 관해 이야기를 나눌 수 있으며 별도의 번역의 절차가 필요 없다.
-
모델은 지식의 정수만을 뽑아낸 것이다.
모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식이다. 모델에는 도메인에 대한 우리의 사고 방식이 담기게 되는데, 이는 용어를 선택하고, 개념을 분류하며 분류한 지식을 서로 연관시키는 과정에서 나오는 산물이다.
개발자와 도메인 전문가는 이 공유된 언어를 바탕으로 갖가지 정보를 모델로 만들어낼 수 있으며 모델과 구현이 연결되어 있다면 더욱 유용하게 활용될 수 있을 것이다.
소프트웨어의 본질
소프트웨어의 본질은 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. 따라서 업무 지식을 증진하기 위해서는 도메인 연구에 몰두해야 하며 모델링 기법을 연마해 도메인 설계에 통달해야 한다.
결국 이 두 가지, 도메인 지식 + 설계 기법을 연마하는 것이 좋은 개발자가 되기 위한 핵심이라고도 볼 수 있다.
여러 과학 분야에서 "복잡성"은 가장 열띤 주제 중 하나이며 많은 연구자들이 현실 세계의 복잡함을 파헤치려는 시도를 하고 있다.
소프트웨어 개발자도 복잡한 도메인에 직면해 명쾌한 모델을 만들어 내는 흥미진진한 일을 할 수 있다. 여기에는 기법이 있다. 체계적인 사고방식과 불규칙하게 뻗어 나가는 소프트웨어 애플리케이션에 질서를 부여할 수 있는 설계 기법을 배우고 연마한다면, 익숙치 않은 도메인에서도 훨씬 더 가치 있는 개발자가 될 수 있을 것이다.
지식 탐구
효과적인 모델링의 요소
-
모델과 구현의 연계
- 초기 프로토타입을 토대로 본질적인 연결 고리를 만든 다음, 이어지는 모든 반복 주기 내내 그 연결 고리를 유지한다.
-
모델을 기반으로 하는 언어 정제
- 실선에서 사용되는 언어, 개념과 개발자의 클래스 다이어그램 간의 간극을 좁히는 작업. 프로젝트가 진행되면서 누구라도 모델에서 바로 용어를 끄집어내어 모델의 구조와 일관되게 의미를 전달할 수 있다.
-
풍부한 지식이 담긴 모델 개발
- 객체는 행위를 지니고 규칙을 이행한다. 모델은 단순히 데이터 스키마가 아니라 복잡한 문제를 해결하는데 필수불가결한 것이다. 모델에는 다양한 지식이 담겨 있다.
-
모델의 정제
- 모델이 점차 완전해지면서 중요한 개념이 더해지고, 쓸모없거나 중요하지 않은 개념은 제거된다. 이 과정에서 불필요한 개념과 필요한 개념이 한데 묶여 있을 경우, 무관한 개념은 모두 제거할 수 있도록 본질적인 개념만 식별할 수 있는 새로운 모델을 고안한다.
-
브레인스토밍과 실험
- 스케치 + 브레인스토밍을 바탕으로 모델에 대한 실험을 진행한다. 수백 가지의 변종을 연습하고 실험하며 평가한다. 이것이 쌓이게 되면 시나리오를 말로만 표현해보아도 제안된 모델의 타당성 여부를 재빨리 판단할 수 있게 된다.
풍부한 지식이 담긴 모델을 발견한고 그러한 모델의 정제를 가능케 하는 것은 바로 브레인스토밍과 수차례에 걸친 실험으로 얻는 창의성이다. 창의성은 모델 기반 언어세어 십분 활용되고, 구현을 통한 피드백 고리로 갈고 닦인다. 이런 식의 지식 탐구는 팀 내 지식을 가치 있는 모델로 만든다.
지식 탐구
지식 탐구의 과정은 보통 팀 단위로 진행된다. 개발자와 도메인 전문가는 위의 단계를 거치면서 협업을 하게 된다.
과거의 "Fall Down" 개발 방식에서는 보통 업무 전문가가 분석가에게 설명하고 다시 분석가는 업무 전문가가 설명한 내용을 바탕으로 스스로 이해해서 추상화해서 소프트웨어를 코드로 작성하는 프로그래머에게 넘긴다.
이러한 방식은 피드백을 전혀 받지 못해서 모델의 책임은 분석가에게 있고, 이 모델을 구성하는 데에는 오로지 업무 전문가에게 받은 내용에 근거하며, 프로그래머에게서 초기 소프트웨어에서의 경험을 쌓을 기회를 얻지 못한다.
훌륭한 프로그래머라면 애초부터 추상화를 시작해서 더욱 많은 일을 가능하게 하는 모델을 만들고 발전시킬 것이다. 하지만 이 같은 과정이 도메인 전문가와의 협업 없이 기술적인 측면에서만 일어난다면 개념은 초보적인 수준에 머무를 것이다.
모든 구성원이 함께 모델을 면밀히 만들어 나가면 팀 구성원 간의 상호작용은 그 양상을 달리 한다. 또 이러한 과정을 거치면 팀원 모두가 유능한 지식 탐구자로 거듭나게 된다. 모두가 모델을 만들어 나가게되므로 모델은 명료하게 조직화되고 추상화될 수 있으며 구현을 더 용이하게 만들어준다.
의사소통과 언어 사용
모델은 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다.
모델 기반 의사소통은 Unified Modeling Language, UML 상의 다이어그램으로 한정돼서는 안 된다.
Agile 프로세스에서 재강조되고 있는 약식 다이어그램뿐만 아니라 텍스트, 코드, 코드 테스트 등을 토대로 의사소통의 향상을 꾀할 수 있다.
공통 언어가 없는 프로젝트에서는 개발자가 도메인 전문가를 위해 자신들의 언어를 번역해줘야 한다. 마찬가지로 도메인 전문가도 개발자 간의 그리고 다른 도메인 전문가 간의 언어를 번역해줘야 한다.
모든 번역에 따르는 부대 비용과 그에 따른 오해의 위험이 있다. 따라서 프로젝트에는 최소 공통 분모보다 좀 더 탄탄한 공통 언어가 필요하다.
모두가 노력을 기울인다면 도메인 모델이 그러한 공통 언어의 근간을 제공할 수 있다.
모델 기반 언어는 개발자 사이에서 시스템의 산출물뿐 아니라 업무와 기능을 기술할 때도 사용해야 한다. 또한 개발자+도메인 전문가, 도메인 전문가+도메인 전문가 가 서로 의사소통하는 데에도 사용되어야 한다.
