도메인 주도 설계의 본질 - 2부[끝]

 

이전 글 : 도메인 주도 설계의 본질 - 1부

순수의 시대

제조, 건축 메타포로부터 파생된 분석/설계/구현의 명확한 분리가 소프트웨어 개발에 적용하기에는 부적합하다는 깨달음과, 애자일 방법론의 대두로 인한 프로세스와 문서화로부터 개인과 팀, 소프트웨어로의 무게 중심 이동, 리팩토링과 피드백을 통한 점진적인 설계 기법의 적용을 통한 분석/설계/구현 사이클 통합, 그리고 엔터프라이즈 애플리케이션 환경에서 표현적 차이를 줄일 수 있는 POJO 중심의 경량 프레임워크의 대두로 소프트웨어 업계는 기민함과 가벼움의 시대로 접어 들었다. 애자일 동맹은 소프트웨어 개발이 기계적인 작업이 아닌 사람의 창조성과 협업에 의한 작업이라는 사실을 일깨워 주었다. POJO와 경량 프레임워크는 소프트웨어가 기술이 아닌 도메인에 의해 주도되어야 한다는 사실을 일깨워 주었다. 기술을 향한 골드러시에 동참했던 사람들의 열기가 서서히 식기 시작했다. 사람들은 발전된 기술에 열광하면서도 과거에 소프트웨어를 개발하던 순수한 방식으로 회귀하기를 갈망했다. 그리고 이러한 방법론과 기술에 대한 기대치가 점점 높아져가고 있던 2003년 Eric Evans는 “Domain-Driven Design”이라는 책을 출판한다.

 

“Domain-Driven Design”은 새로운 개념이 아니다. 책의 부제인 “Tackling Complexity in the Heart of Software”에서 알 수 있듯이 DDD는 소프트웨어의 본질적인 문제인 복잡성을 제어하기 위해 기존에 존재해 왔던 다양한 방법과 기법들을 패턴 언어Pattern Language 형식으로 정리해 놓은 것이다. DDD가 전혀 새로운 기법을 제시하지 않고 있음에도 불구하고 많은 사람들이 그것에 열광하는 이유는 DDD의 접근 방식에 있다. DDD는 소프트웨어 개발의 베스트 프랙티스를 도메인이라는 컨텍스트 안에서 체계적으로 조합하고 연결시킨다. DDD는 “모든 소프트웨어 복잡성은 도메인에 기인한다”는 매우 일반적이고 직관적인 명제로부터 출발한다.

 

애자일 연맹이 소프트웨어를 개발하는 본질이 사람이라는 사실을, POJO가 소프트웨어 구성 단위의 본질이 순수한 객체라는 사실을 묻혀있던 과거의 기억 속에서 끄집어 냈다면, DDD는 우리가 기술의 홍수 속에서 잊고 있었던 소프트웨어가 딛고 있는 땅의 본질이 도메인이라는 사실을 깨닫게 해준다. DDD의 가치는 과거로부터 중요하고 본질적이라고 믿어 왔던 가치들을 현재의 복잡한 엔터프라이즈 애플리케이션 환경에 적용 가능한 수준으로 확장했다는 점에 있다. 즉, 눈부시게 빠른 속도로 발전하는 기술의 변화에 유연하게 대처하면서도 소프트웨어의 본질인 도메인의 표현을 가능하게 해주는 패턴과 기법의 복합체가 바로 DDD인 것이다.

 

DDD는 도메인 모델과 소프트웨어 모델, 즉 코드 간의 표현적 차이를 최소화하기 위한 접근 방법이다. 이를 위해 EJB와 같은 구현 기술이 소프트웨어 개발을 주도함으로써 발생되는 여러 가지 문제점을 해결하기 위해 기술 주도적인 방식이 아닌 도메인 주도적인 방식으로 소프트웨어를 개발할 것을 주장한다.

 

DDD를 성공적으로 적용하기 위해서는 기본적으로 두 가지 요소가 갖추어져야 한다. MODEL-DRIVEN DESIGN과 UBIQUITOUS LANGUAGE가 바로 그것이다. 두 가지 원리를 이해하기 위해 모델과 소프트웨어의 관계에 관해 간략히 살펴 보기로 하자.

MODEL과 DOMAIN-DRIVEN DESIGN

모델(Model)은 대상을 단순화한 것이다. 모델은 추상화다. 즉, 모델은 얽히고 설킨 복잡한 사실에 대한 하나의 해석이며, 당면한 문제를 해결하기 위해 필요한 측면을 강조하고 문제 해결에 무관하거나 불필요한 세부사항에는 의도적으로 주의를 기울이지 않는다. 사실과 완전히 동일한 모델을 만드는 것은 바람직하지 않다. 모델은 현실이라는 기반 위에 해결하고자 하는 문제에 적합한 새로운 추상화 계층을 창조하는 과정이다. ‘천하도’는 과거 사람들이 생각하던 세계의 모델이다. 천하도가 세계의 모습과 완전히 동일하지 않다고 해도 과거 사람들의 세계관을 적절히 반영하고 있기 때문에 적합한 모델이라고 할 수 있다.

 

모든 소프트웨어는 특정한 사용자의 문제를 해결하는 것을 목적으로 한다. 이 때 소프트웨어를 사용할 사용자의 활동이나 관심사의 대상이 되는 영역을 소프트웨어의 도메인(Domain)이라고 한다. 따라서 도메인 모델(Domain Model)이란 소프트웨어가 문제를 해결해야 하는 대상 영역을 단순화시키고 추상화시킨 것이다. 적절한 도메인 모델을 선택함으로써 소프트웨어 개발과 관련된 다양하고 복잡한 측면들을 이해할 수 있고 해결하려는 문제에 집중할 수 있다.

 

도메인 모델은 어떤 특정한 다이어그램이나 문서가 아니라 이를 통해 전달하고자 하는 개념의 집합이다. 도메인 모델은 단지 도메인 전문가의 머리 속에만 존재하는 지식이 아니라 소프트웨어 개발에 적합하도록 지식을 정밀하게 조직하고 선택적으로 추상화한 것이다.

 

소프트웨어의 본질적인 복잡성은 도메인의 복잡성에 기인한다. Frederick Brooks의 말을 재인용하면 소프트웨어의 본질적인 문제를 외면한 상태에서 비약적인 생산성의 향상을 기대할 수는 없다. 따라서 소프트웨어의 본질적인 문제를 해결하기 위해서는 도메인을 이해하고 끊임없는 탐구를 통해 적절한 도메인 모델을 선택하는 것이 중요하다.

그림 5 도메인 모델을 중심으로 소프트웨어 개발을 진행하라

 

훌륭한 도메인 모델은 다음의 3가지 요구사항을 충족시킨다.

• 모델과 핵심 설계는 상호 영향을 주고 받으며 구체화된다.
  모델과 구현 간의 긴밀한 연결과 피드백을 통해 모델이 의미를 가지도록 하고 최종 산출물인 동작하는 프로그램이 사용자의 요구사항을 만족시킬 수 있도록 보장한다. 모델과 구현을 연결 시키는 것은 분석/설계/구현을 동일한 사이클로 묶음으로써 달성된다. 애자일의 언제나 설계하기 사상, 즉 리팩토링을 통한 점진적인 설계는 모델과 구현의 불일치를 예방하기 위한 프로세스적인 장치다. 모델과 구현이 일치하기 위해서는 모델과 코드의 표현적 차이가 적어야 한다. 코드가 인프라스트럭처에 대해 강하게 의존할 경우 모델과 코드 간의 표현적 차이가 커진다. POJO 기반의 경량 프레임워크 기술이 인프라스트럭처의 늪에서 코드를 구원한다. 모델을 기반으로 분석/설계/구현을 통합하고 피드백을 통해 개선시키는 과정을 MODEL-DRIVEN DESIGN이라고 한다.
• 모델은 모든 팀 구성원들이 사용하는 언어의 근간을 이룬다.
  모델과 구현이 긴밀하게 연관되어 있으므로 개발자들은 모델을 사용해서 대화할 수 있다. 모델은 도메인 전문가가 도메인을 바라보는 관점을 담고 있기 때문에 도메인 전문가 간의 대화 시에 사용할 수 있다. 개발자와 도메인 전문가 간에 공통의 모델을 공유하기 때문에 별도의 번역 과정 없이 개발자와 도메인 전문가 사이에에 모델을 기반으로 의사소통 할 수 있다. 애자일 동맹에서 강조하는 문서에 의한 지식 전달이 아닌 직접 대면과 대화를 통한 의사소통 방식은 언어의 중요성을 강조한다. 모델은 소프트웨어 지식의 집합체이며 정보 흐름의 통로다. 이해관계자들 간의 의사소통에 사용되는 언어에 변화가 생기면 모델의 용어가 변경되고, 모델의 용어가 변경되면 코드가 수정된다. 반대로 코드가 변경될 경우 모델과 의사소통에 사용되는 용어가 변경된다. 모델은 이해관계자들의 공통 언어인 UBIQUITOUS LANGUAGE를 구성하는 기반이다.
• 모델은 불순물을 걸러낸 핵심 지식만을 포함한다.
  효과적인 도메인 모델은 끊임없는 지식 탐구 활동과 개선을 통해 얻어진다. 수많은 모델을 시도하고, 버리고, 변형한 끝에 도메인의 모든 세부 사항에 적절한 일련의 추상적 개념들을 발견함으로써 적절한 도메인 모델을 얻게 된다. 지식 탐구 활동은 개발자와 도메인 전문가 간의 긴밀한 협력이 전제되어야 한다. UBIQUITOUS LANGUAGE가 빛을 발휘하는 때다. 지식 탐구 활동은 끊임없이 모델과 코드를 개선하는 정제 과정이다. 모델과 코드를 긴밀히 연결함으로써 새로운 통찰이 모델과 코드에 반영되도록 할 수 있다. MODEL-DRIVEN DESIGN이 우리를 정제의 길로 인도한다. 끊임없는 정제가 가능하기 위해서는 소스 코드를 항상 깨끗하고 안정적인 상태로 유지해야 한다. 애자일의 언제나 설계하기 사상과 분석/설계/구현 사이클의 통합, 리팩토링을 통한 점진적인 설계 방식은 이를 가능하게 한다.

DDD는 훌륭한 도메인 모델을 만들고 이를 소프트웨어 반영하기 위한 모든 것이다.

MODEL-DRIVEN DESIGN

MODEL-DRIVEN DESIGN 의 개념은 간단하다.  도메인 모델을 반영하는 코드를 작성하라. 코드에 나타나는 구조와 용어는 도메인 모델에 기반해야 한다. 도메인에 대한 이해가 바뀐다면 이를 도메인 모델과 코드 양쪽 모두에 반영하라. 만약 모델이 코드를 작성하기에 적합하지 않다면 구현에 적합하도록 모델을 수정하라. 모델과 코드의 개념적 거리가 멀어지면 멀어질수록 소프트웨어는 도메인과 멀어지고, 도메인 전문가와 개발자는 서로 간의 개념을 일치시키기 위해 번역 과정을 거쳐야 하므로 의사소통이 어려워지고 유지보수가 어려운 코드를 얻게 된다. 모델을 기반으로 코드를 작성하되 모델과 코드를 동기화하기 위해 모든 노력을 쏟아라.

 

MODEL-DRIVEN DESIGN을 적용하기 위해서는 분석/설계/구현이 개별적인 활동이라는 환상에서 벗어나야 한다. 이를 하나의 사이클로 묶음으로써 모델과 코드 간의 거리를 좁히도록 노력해야 한다. 둘 사이의 개념적 거리가 멀어지면 지속적인 리팩토링을 통해 간격을 좁히도록 최선을 다해야 한다.

 

모델링과 구현이 개별적인 사람들에 의해 이루어져야 한다는 착각 역시 MODEL-DRIVEN DESIGN을 방해하는 요소다. 구현에 관여하는 사람들은 모델링 작업에 직접 참여해야 한다. 두 역할을 분리할 경우 모델링 작업에서 얻어지는 지식이 코드에 반영되지 못한 채 소리 없이 사라져 버리게 된다. 또한 구현 과정에서 얻어지는 통찰을 모델에 반영할 수 없게 되므로 결과적으로 코드와 모델 간의 연결 고리가 점점 약해지게 된다. 코드는 모델이며, 모델은 코드다. 극단적인 흑백논리는 소프트웨어 개발에 있어 최대의 적이다.

 

모델과 코드 간의 표현적 차이를 줄이기 위해서는 도메인 전문가와 개발자 간에 동일한 언어를 기반으로 의사소통하는 것이 중요하다. 역동적이고 활동적인 UBIQUITOUS LANGUAGE가 MODEL-DRIVEN DESIGN의 기반을 이룬다.

 

도메인 모델과 소프트웨어 시스템 간의 맵핑이 명확해지도록 도메인 모델을 충실하게 반영하는 소프트웨어 시스템을 설계하라. 도메인에 대한 더 깊은 식견을 반영할 방법을 찾는 순간 소프트웨어 내에서 모델을 더 자연스럽게 구현할 수 있도록 모델을 재검토하고 수정하라.  견고한 UBIQUITOUS LANGUAGE를 지원함과 동시에 두 가지 목적 모두에 잘 부합하는 하나의 모델을 추구하라.

설계에서 사용되는 용어와 기본 책임 할당을 사용해서 모델을 작성하라. 코드는 모델의 표현이 되고 코드에 대한 수정은 모델에 대한 수정이 된다. 효과는 나머지 프로젝트 활동 내내 적절히 파급되어야 한다.

Eric Evans, Domain-Driven Design

UBIQUITOUS LANGUAGE

바벨탑을 쌓아 신의 권위에 도전하려던 인간의 오만은 결국 신의 분노로 인해 실패하고 만다. 인류 역사상 가장 거대한 공학 프로젝트인 동시에 가장 큰 프로젝트 실패 사례로 꼽히는 바벨탑의 가장 큰 실패 요인은 언어의 분할로 인해 이해관계자 간에 의사소통이 불가능해졌다는 것이다. 신의 권위에 도전하지 않는 현대의 소프트웨어 프로젝트에 있어 불가능한 의사소통이 프로젝트를 실패하게 만들지는 않을 지라도 그 길을 더디고 험난하게 만들 수는 있다.

그림 6 의사소통의 단절로 인해 실패한 바벨탑 프로젝트

 

도메인 전문가와 개발자가 서로 다른 용어를 사용할 경우 두 역할 간의 의사소통을 위해 번역 작업이 수반되어야 하며, 이는 곧 의사소통의 효율성 저하, 두 역할 간의 불협화음으로 인한 프로젝트 능률 저하, 도메인과 격리된 코드라는 결과를 낳게 된다. 따라서 프로젝트에 참여하는 모든 이해관계자들이 의사소통 시에 사용할 수 있는 공통 언어가 필요하다.

 

도메인 모델은 도메인에 대해 이해관계자들이 가지고 있는 관점과 지식의 축적이며 추상화의 산물이다. 도메인 모델 내에 표현된 모든 개념과 관계는 도메인을 바라보는 이해관계자들의 지식 탐구 활동을 통해 얻어진 통찰이 반영되어 있다. 따라서 도메인 모델은 이해관계자들의 의사소통을 위한 공통 언어 구축의 핵심 요소로 사용할 수 있다. 도메인 모델을 기반으로 한 공통 언어는 소프트웨어 개발과 관련된 전반적인 활동의 중심에 모델을 위치시키며, 결과적으로 모델과 코드를 연결시키기 위한 MODEL-DRIVEN DESIGN에 있어 매우 중요한 연결고리를 제공한다.

 

모델을 언어의 기반으로 삼아라. 팀에서 이루어지는 모든 의사소통과 코드에 적극적으로 공통의 언어를 적용하라. 다이어그램과, 문서화, 특히 대화에 동일한 언어를 사용하라.

 

여러 가지 모델을 반영하는 다른 표현을 실험해봄으로써 공통 언어 선택에 따르는 어려움을 해소하라. 그 후 새로운 모델에 적합하도록 클래스, 메서드, 모듈의 이름을 변경하여 코드를 리팩토링하라. 일상에서 사용하는 용어를 다르게 사용할 경우 의미에 대한 공감대를 형성하는 것과 동일한 방식으로 대화에 사용하는 용어 상의 혼란 역시 해결하라.

UBIQUITOUS LANGUAGE의 변경은 곧 모델의 변경이라는 사실을 인식하자.

Eric Evans, Domain-Driven Design

 

애자일 진영은 문서나 다이어그램을 통한 의사소통보다는 직접 대면과 대화를 통한 의사소통 방식을 선호한다. UBIQUITOUS LANGUAGE를 확립하기 위해서는 대화와 같은 직접적인 의사소통 수단을 적극 활용하여 언어가 팀 전체에 골고루 퍼지게 해야 한다. 언어가 널리 사용되면 사용될수록 이해관계자들 간의 원활한 의사소통이 가능해진다. 형식적인 문서화도 중요하지만 가능하면 언어가 지닌 장점을 최대한 활용하라.

 

UBIQUITOUS LANGUAGE의 용어와 개념이 도메인에서 사용되는 개념이라고 해서 반드시 도메인 전문가들이 사용하는 용어만으로 구성되는 것은 아니다. 도메인 전문가의 용어 중 실제 소프트웨어가 해결하려는 컨텍스트와 관련된 용어들만이 UBIQUITOUS LANGUAGE에 포함된다. 또한 개발에 필요한 용어 중 도메인 전문가와 개발자 간의 의사소통을 위해 필요한 용어들 역시 UBIQUITOUS LANGUAGE에 포함된다. 따라서 UBIQUITOUS LANGUAGE는 도메인 전문가들이 사용하는 용어 일부와 개발자들이 사용하는 용어 일부로 구성된다.

그림 7 도메인 전문가와 개발자 용어의 교집합으로 구성된 UBIQUITOUS LANGUAGE

 

UBIQUITOUS LANGUAGE 상의 용어에 변경이 발생하면 곧 모델, 코드에 대한 변경으로 파급되어야 한다. 역으로 코드에 사용된 어떤 용어가 수정될 경우 변경 사항은 모델과 UBIQUITOUS LANGUAGE로 파급되어야 한다. 가장 중요한 것은 변경 전의 용어를 폐기처분하고 일상적인 의사소통, 특히 대화 시에 새로운 용어를 사용하도록 노력하는 것이다.

그림 8 UBIQUITOUS LANGUAGE와 코드 간의 순환 관계

패턴에 대해서

DDD를 접하는 대부분의 사람들이 가장 먼저 접하게 되는 것이 ENTITY, VALUE OBJECT, AGGREGATE, SERVICE, REPOSITORY와 같은 패턴이다. 지면상의 제약으로 인해 본 글에서 DDD의 패턴에 대해 포괄적으로 설명하기는 어려울 것으로 판단되어 여기에서는 DDD의 패턴을 바라보는 개인적인 견해를 피력하는 정도로 마무리하고자 한다.

 

패턴에 대한 자세한 내용이 궁금한 사람들은 Eric Evans가 저술한 “Domain-Driven Design”을 읽어 보기 바란다. 부족하나마 필자의 블로그(http://aeternum.egloos.com/)에 올려져 있는 글을 읽어 보는 것도 도움이 되리라고 생각한다. 웹에서 얻을 수 있는 Domain Driven Design Quickly와 Domain-Driven Design Step-By-Step 역시 패턴을 이해할 수 있는 유용한 정보를 얻을 수 있다.

 

개인적으로 도메인 모델을 반영한 코드를 작성하고, 도메인 모델과 코드가 상호 연결된 관계를 유지할 수 있도록 해 주는 두 가지 핵심 원리인 UBIQUITOUS LANGUAGE와 MODEL-DRIVEN DESIGN이 DDD의 핵심을 이루는 개념이라고 생각한다. 따라서 위 두 가지 원리를 이해하는 것이 DDD의 개별 패턴을 이해하는 것 보다 더 중요하다.

 

그렇다고 해서 패턴이 중요하지 않다는 것은 아니다. 원리를 이해하는 것과 이를 실천하는 것은 별개의 문제다. DDD에서 제시하는 패턴은 DDD의 기본 원리를 실행할 수 있는 기반을 제공한다는 점에서 그 가치가 매우 높다. 그러나 기본적인 원리의 이해 없이 성급하게 개별 패턴을 적용하려는 시도는 위험하다. DDD의 패턴에서 차용된 Annotation을 코드에 사용하고 DDD를 지원한다고 선전하는 프레임워크를 적용한다고 해서 DDD를 적용하는 것은 아니다.

그림 9 패턴은 중요하다. 그러나 원리가 그보다 더 중요하다.

 

패턴의 적용 유무와 무관하게 다음 질문에 대해 모두 YES라고 대답할 수 있다면 DDD를 실천하고 있다고 봐도 무방하다.

• 모든 이해당사자들이 이해하는 도메인 모델이 존재하는가?
• 모든 이해당사자들이 의사소통에 사용하는 UBIQUITOUS LANGUAGE가 존재하는가?
• 소프트웨어가 MODEL-DRIVEN DESIGN 방식으로 개발되고 있는가?

그래도 은 총알은 없다

DDD는 끊임없는 지식 탐구 활동을 통해 적절한 도메인 모델을 선택하고, 선택된 도메인 모델을 기반으로 분석, 설계, 구현에 걸친 소프트웨어 개발 전 과정을 주도하고, 모델을 의사소통의 핵심 수단으로 사용하기 위해 적용할 수 있는 기법과 패턴의 집합이다. 그렇다면 DDD가 과연 우리가 찾고 있던 은 총알인가? 그렇지는 않다고 생각한다. DDD를 소프트웨어 개발과 관련된 모든 문제를 해결해 줄 수 있는 만병 통치약으로 생각해서는 안 된다.

 

DDD는 장점이 많은 만큼 적용에 따르는 리스크와 제약 역시 크다. 그렇다면 DDD를 적용해야 하는 때는 언제인가? 이에 대한 Casey Charlton의 견해를 들어 보자.

 

DDD는 다음과 같은 경우 적용하기 적절한 소프트웨어 방법이다 – 매우 복잡하고 잘 정의된 비즈니스 모델에 초점을 맞추어야 하는 소프트웨어.

아마 모든 소프트웨어 애플리케이션의 95%는 “DDD를 적용하기에 적절하지 않은” 범주에 속할 것이다. 대부분의 소프트웨어는 근본적으로 데이터 중심적이다 – 대부분의 웹 사이트가 그렇고, 대부분의 데스크톱 애플리케이션이 그렇다. 사실 데이터를 수정하고 보고하는 대부분의 애플리케이션은 데이터 중심적이라고 할 수 있다. 나머지 부류의 애플리케이션이라고 하더라도 매우 복잡한 도메인을 가진 경우는 많지 않다. 대부분은 단순하거나, 소프트웨어의 규모가 크더라도 그렇게 복잡하지는 않다.

DDD를 적용하기에 적절한 나머지 5%의 애플리케이션에 대해서는 DDD를 적용하기에 매우 적합하다고 할 수 있다. 그런 상황에서 DDD를 적용하는 것은 어렵고 복잡한 문제를 해결하는데 있어 매우 큰 도움이 될 것이다. 이런 상황이라면 DDD는 늑대를 물리치기 위한 은 총알이 될 지도 모른다.

비록 애플리케이션이 DDD에 적합한 5% 범주에 포함되지 않는다고 하더라도 DDD에는 대량의 지혜와 경험이 녹아 있다 – 자신의 상황에 적용할 수 있다고 생각되는 기법을 적용하면 소프트웨어가 좀 더 유연해지고, 사용자에게 더 잘 반응하며, 이해하기 더 쉬워짐을 알게 될 것이다.

Casey Charlton, Domain Driven Design Step by Step Guide

 

DDD는 복잡한 도메인을 공략하기 위한 최상의 설계 지침을 제공한다. DDD의 가치는 소프트웨어의 부차적인 문제가 아니라 본질적인 문제를 해결하기 위해 모든 사람들의 역량을 모을 수 있도록 해준다는데 있다.

비록 DDD의 지침을 현재의 프로젝트에 적용할 수 없는 상황에 있다고 하더라도 DDD의 세계에 발을 들여 놓는 것이 큰 도움이 될 것이라 생각된다. Eric Evans의 충고에 귀를 기울여 보자.

개발자들이 [도메인에 대한] 통찰을 얻기 위해 적용할 수 있는 체계적인 사고 방법이 존재한다. 무질서하게 뻗어 나가는 소프트웨어 애플리케이션에 질서를 부여할 수 있는 설계 기법 역시 존재한다. 이런 기술을 연마한다면 익숙하지 않은 도메인을 접하게 될 경우에도 더 가치 있는 개발자로 발전할 수 있게 될 것이다.

Eric Evans, Domain-Driven Design