Domain Driven 과 Model Driven

도메인 드리븐 설계와 모델 드리븐 설계 간의 차이는 무엇인가? 이름이 비슷하고 두 개념이 서로 경계를 넘나들기 때문에 이 두 개념은 종종 혼동된다. 하지만 이 두가지 개념은 서로를 강력하게 해주는 소프트웨어 개발을 접근하는 서로 다른 방법이다.

도메인 드리븐 설계는 소프트웨어 개발의 핵심이 다루고자 하는 주제(subject matter)의 지식이라는 전제와 해당 다루고자 하는 주제를 이해하는 유용한 방법을 찾는 것으로부터 시작되었다. 해결해야만 하는 복잡성이 도메인의 복잡성 그 자체이다. - 기술적인 아키텍처도 아니고, 사용자 인터페이스도 아니고, 특정 성질의 것은 더욱 아니다. 이는 업무의 가장 핵심적인 개념에 대한 이해와 개념화(conception)를 둘러싼 모든 것을 설계하고 그러한 핵심을 지원하는 방법에 의한 어떠한 개발을 정당화하는 것을 의미한다.

이를 달성하기 위해서 도메인 전문가와 소프트웨어 전문가는 소프트웨어 개발의 목적을 달성하는 도메인의 지식을 구조화시키는 방법을 찾기 위해서 함께 실험을(experiment) 해야 한다. 이들은 다루고자 하는 주제(subject matter)에 몰두해야 하며, 이 주제가 이들을 이끌며, 최우선으로 도메인에 대해서 표현하고 논리적으로 생각하는 데에 소프트웨어를 구축하는 우선권을 부여해야 한다. 이들은 해당 도메인의 표면적인 부분을 떨쳐버리고 핵심 원리를 파헤쳐야 한다.

명확한 개념으로 지식을 정화하는 것이 모델링 과정(process)이다. 그러한 모델은 해당 팀의 언어 내에 존재하며, 해당 언어의 모든 대화가 모델링 회의가 될 수 있다. 또한 모델링이 복잡한 도메인을 이해하는 데에 사투를 벌이는 방법이기 때문에 도메인 드리븐 설계는 필연적으로 모델링을 낳게 된다.

어떤 팀에서는 트랜잭션 스크립트나 모델 기반 소프트웨어가 아닌 다른 형태로 코드를 작성할 수도 있는데, 이러한 도메인에 대한 이들의 공유된 이해는 프로그래머들 자신이 해당 지식을 공유한다는 전제하에 여전히 가치가 있을 것이다.

하지만 모델이 유포되었을 때에 모델은 완전하게 제 역할을 하지 못한다. 소프트웨어가 여전히 강조하는 모든 문제는 설계에서 해결되어야만 한다. 모델이 부적절하거나 심지어 잘못 이끌 수도 있는 위험성이 있다. 모델에 실효성을 높일 필요가 있다.

모델 드리븐 설계는 몇가지 개념을 아울러서 실질적으로 만들어진 소프트웨어이다. 예를 들어, UI 프레임워크는 윈도우나 메뉴와 같은 UI 개념들이 실제의 소프트웨어 구성들과 대응된다면 모델 드리븐 설계를 가지게 될 것이다. 어떤 UI 프레임워크는 이러한 방식으로 설계되어 있는 반면에 다른 것들은 원하는 결과를 얻기 위한 기능을 단순하게 제공한다.

따라서 모델 드리븐 설계는 UI와 기반 구조에 기술적인 문제에 적용될 수 있다. 하지만 이것은 개발 프로젝트를 시작하게 하는 도메인에 모델 드리븐 설계를 적용하는 것이다. 개발자들이 도메인에 깊이 파묻힐수록 도메인 전문가들과 지식에 대해서 세밀하게 분석하고(crunching), 자신들의 생각으로 모델을 정제시키고(distilling) 널리 사용되는 언어(ubiquitous language)로 연습을 함으로써 공유된 모델을 잘 손질하는(cultivating) 것이 공유된 모델을 키우는(nurture) 것이다. 모델 드리븐 설계는 그러한 모델을 소프트웨어의 구조 속으로 넣는다. 마지막으로 피드백 순환은 구현과 도메인 지식 사이를 메운다.

모델 드리븐 설계에서, 설계는 모델에 기반하는 것 뿐만 아니라, 모델 역시 설계와 구현에 대한 고려사항을 적합하게 하기 위해서 선택된다. 이러한 두개의 제약사항은 반복(iteration)을 통해서 동시에 해결된다. 부분적으로 이러한 것은 우리들의 특정 하드웨어나 특정 프로그래밍 언어 혹은 기반 구조의 실질적인 한계를 반영한다. 이것이 중요하지만, 훨씬 더 근본적인 것 역시 발생한다. 프로그래밍은 여타 다른 방법(최소한 비용에 효과적이 아닌)으로 결코 알아채지 못할 수도 있는 로직에서 포착하기 어렵지만 중요한 묘안(wrinkle)을 드러낸다. 이러한 것들이 모델 드리빈 설계의 코딩에서 완전히 무시될 때 프로그래머들은 그러한 묘안을 맞추는 도메인에 대해서 자신들의 생각을 정제한다. 모델 드리븐 설계의 사상을 받아들이는 팀은 코드의 변경이 모델의 변경이라는 사실을 알아야 한다. 자그마한 변칙들이 모델에서 큰 변화를 가지고 오는 단초가 될 것이다.

Domain-Drven Design이라는 책에서 나는 많은 금융 트랜잭션에서 잔금의 한계를 정하는 어려움이 심오한 새로운 통찰력과 중요한 재설계를 이끌어 냈을때의 경험에 대해서 썼다. 절차적인 프로그래밍에서 이러한 것은 발생할 수 있지만, 코드는 우리들의 머리와 언어에 있는 도메인에 대한 생각과 밀접하게 닮지 않기 때문에 두가지 형태의 생각은 분리된다는 가능성은 훨씬 적다.

이것이 왜 모델 드리븐 설계가 도메인 드리븐 설계와 같이 동행하는데 필수적이 아니라고 했을때 적합한지를 나타낸다. 도메인에 대한 깊은 이해가 도메인 전문가들과 프로그래머들의 생각으로부터 이들이 널리 사용하는 언어를 통해, 혹은 소프트웨어 그 자체를 통해서 최종 사용자에게까지 - 역방향도 마찬가지로 - 모든 방법을 도달하게끔 한다.

[원문]