domain-driven-design

03장. 모델과 구현의 연계

Introduction

• 프로젝트에 도메인 모델은 있었지만, 동작하는 소프트웨어를 개발하는 데 직접적으로 도움을 주지 않는 한 종이에 기록된 모델이 무슨 의미가 있겠는가?
• 도메인 주도 설계에서는 초기 분석 단계에 도움될 뿐 아니라 설계의 기반이 되는 모델이 필요하다.

MODEL-DRIVEN DESIGN (모델 주도 설계)

• 코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.
• 분석 모델 (analysis model)
  • 설계와 뚜렷이 구분되고 보통 다른 사람이 만듦
  • 분석 모델이라고 하는 이유
    • 분석 모델이 소프트웨어 시스템에서 수행한 역할에 대해 고려하지 않은 채 업무 도메인의 개념만을 체계화하고자 해당 업무 도메인을 분석한 결과물이기 때문
  • 분석 모델은 오로지 이해하기 위한 수단으로만 간주됨
  • 구현 관심사와 섞일 경우 혼란만 초래하는 것으로 여겨짐
• 순수하게 이론에만 치우친 분석 모델은 심지어 도메인의 이해라는 가장 주된 목표에 미치지 못하기도 하는데, 중요한 발전은 언제나 설계/구현 을 위해 노력하는 가운데 나타나기 때문
• 결과적으로 순수하게 이론에만 치우친 분석 모델은 코딩이 시작되자마자 폐기되고 대부분의 문제를 다시 검토해야 함
• 설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면 그 모델은 그다지 가치가 없으며 소프트웨어의 정확함도 의심스러워진다.
• 동시에 모델과 설계 기능 사이의 복잡한 대응은 이해하기 힘들고, 실제로 설계가 변경되면 유지보수가 불가능해진다.
• 분석과 설계가 치명적으로 동떨어지고, 그에 따라 각자의 활동에서 얻은 통찰력이 서로에게 전해지지 않는다.
• MODEL-DRIVEN DESIGN 에서는 양쪽 모두의 목적을 달성하는 단일 모델을 찾기 위해 분석 모델과 설계를 나누는 이분법은 채택하지 않는다.
• 소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 하라.
• 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게 수정하라.
• 도메인에 관한 더욱 심층적인 통찰력을 반영하려 할 때도 마찬가지다.
• 이렇듯 견고한 UBIQUITOUS LANGUAGE 를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만들어 내야 한다.
• 모델로부터 설계와 기본적인 책임 할당에 사용한 언어를 도출하라.
• 코드를 작성할 때 그러한 용어를 사용하면 코드가 모델을 표현한 것이 되고, 코드의 변경이 곧 모델의 변경으로 이어질 수 있다.
• 그 효과는 프로젝트의 나머지 활동에도 퍼져나가야 한다.
• 구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래밍과 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요하다.

모델링 패러다임과 도구 지원

• 객체지향 프로그래밍은 모델링 패러다임에 근거하고 모델의 구성요소에 대한 구현을 제공하기 때문에 매우 효과적
• 순수하게 절차적인(procedural) 언어에 대응되는 모델링 패러다임은 없다.
• 대부분의 수학적이지 않은 도메인은 절차적인 언어로 MODEL-DRIVEN DESIGN 을 하기에는 적합하지 않은데, 이는 도메인이 수학 함수나 절차상의 단계로 개념화되지 않기 때문

내부 드러내기: 왜 모델이 사용자에게 중요한가

• 실제로 사용자가 바라보는 것과 시스템이 불일치한다면 혼란을 일으킬 수도 있고, 최악의 경우에는 버그를 유발할 수 있다.
• MODEL-DRIVEN DESIGN 에서는 오로지 하나의 모델을 다룰 것을 요구
• 물론 도메인 모델을 있는 그대로 바라보는 것은 확실히 대부분의 경우 사용자에게 편리하지 않을 것
• 설계가 사용자와 도메인 전문가의 기본적인 관심사를 반영하는 모델에 기반을 두면 설계의 골격이 다른 설계 접근법에 비해 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다.
• 모델이 드러나면 사용자가 소프트웨어 잠재력을 좀 더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타날 것이다.

HANDS-ON MODELER (실천적 모델러)

• 코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동작하게 만드는 법을 모른다면 그 모델은 소프트웨어와 무관해진다.
• 코드의 변경이 곧 모델의 변경이라는 점을 개발자가 인식하지 못하면 리팩터링은 모델을 강화하기 보다는 약화시킬 것이다.
• 한편으로 모델러가 구현 프로세스와 분리되어 있을 경우, 구현상의 제약조건을 감안하는 능력을 결코 갖추지 못하거나 금방 잃어버릴 것
• 모델이 효과적인 구현을 뒷받침하고 핵심 도메인 지식을 추상화한다는 MODEL-DRIVEN DESIGN의 기본적인 제약조건은 절반쯤 사라지고, 결과로 나타나는 모델은 실용적이지 못할 것이다.
• 결국 MODEL-DRIVEN DESIGN을 코드로 만드는 과정의 미묘한 사항들은 협업을 통해 알 수 있는데, 설계자가 구현을 하지 못해 개발자와 업무의 단절이 생기면 숙련된 설계자의 지식과 솜씨는 결코 다른 개발자에게 전해지지 못할 것이다.
• 모델에 기여하는 모든 기술자는 프로젝트 내에서 수행하는 일차적 역할과는 상관없이 코드를 접하는 데 어느 정도 시간을 투자해야만 한다.
• 코드를 변경하는 책임이 있는 모든 이들은 코드를 통해 모델을 표현하는 법을 반드시 배워야 한다.
• 모든 개발자는 모델에 관한 일정 수준의 토의에 깊이 관여해야 하고 도메인 전문가와도 접촉해야 한다.
• 다른 방식으로 모델에 기여하는 사람들은 의식적으로 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE 를 토대로 모델의 아이디어를 나누는 데 적극 참여해야 한다.
• 도메인 주도 설계는 모델을 동작하게 만들어 애플리케이션의 문제를 해결
• MODEL-DRIVEN DESIGN 은 모델과 구현을 매우 밀접하게 연결함
• UBIQUITOUS LANGUAGE 는 개발자와 도메인 전문가, 소프트웨어 사이에 흐르는 모든 정보의 통로에 해당
• 그리고 그 결과는 핵심 도메인의 근본적인 이해를 토대로 한, 기능이 풍부한 소프트웨어
• MODEL-DRIVEN DESIGN 의 성공은 세부적인 설계 결정에 민감하게 영향을 받음