• 도메인 주도 설계에서는 초기 분석 단계에 도움될 뿐 아니라 설계의 기반이 되는 모델이 필요

  1. 큰 벽 전체를 덮고 있는 종이에 인쇄된 전체 클래스 다이어그램
  2. 기존의 C++로 작성된 애플리케이션을 자바로 구현한 새로운 설계로 대체하는 프로젝트

  → 두 산출물 모두 기능성은 갖췄지만 비대했고 매우 이해하기 어려웠으며, 결국 유지보수가 불가능

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

• 도메인 모델은 전혀 없고 기능만 차례로 구현하기 위해 코드를 작성하는 것은 지식 탐구와 의사 소통 이점 X
• 모델과 코드 간의 연결이 끊어지는 경우, '분석 모델'의 필요성을 지지하는데 모델과 설계의 연결은 어려움
• 순수하게 이론에만 치우치고 설계의 기반이 되는 개념이 부족한 소프트웨어는 유익한 일을 수행하는 메커니즘일 뿐

설계 혹은 설계의 주된 부분이 도메인 모델과 대응하지 않는다면 그 모델은 그다지 가치가 없으며 
소프트웨어의 정확함도 의심스러워진다. 동시에 모델과 설계 기능 사이의 복잡한 대응은 이해하기 힘들고, 
실제로 설계가 변경되면 유지보수가 불가능해진다. 분석과 설계가 치명적으로 동떨어지고, 
그에 따라 각자의 활동에서 얻은 통찰력이 서로에게 전해지지 않는다.

• MODEL-DRIVEN DESIGN에서는 아래 양쪽 모두의 목적을 달성하는 단일 모델을 찾기 위해 이분법으로 나누지 않는다
  1. 분석: 도메인의 근본적인 개념을 알기 쉽고 표현력있는 방식으로 포착
  2. 설계: 대상 배포 환경에서 효율적으로 수행되고 애플리케이션에서 다뤄야 할 문제를 올바르게 해결할 수 있는 구성요소를 기술해야 하며, 이러한 구성 요소는 프로젝트에서 사용중인 프로그래밍 도구로 구현
• 위의 접근법에는 분석과 설계 관점에서 모두 효과적인 모델이 필요하고, 그렇지 않으면 새로운 모델로 방향

소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 
분명하게 하라. 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게 수정하라. 
도메인에 관한 더욱 심층적인 통찰력을 반영하려 할 때도 마찬가지다. 이렇듯 견고한 
UBIQUITOUS LANGUAGE를 지원하는 것과 더불어 분석과 설계의 두 가지 측면을 충분히 만족하는 
단 하나의 모델을 만들어내야 한다.
모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출하라. 코드를 작성할 때 그러한 용어를 
사용하면 코드가 모델을 표현한 것이 되고，코드의 변경이 곧 모델의 변경으로 이어질 수 있다. 
그 효과는 프로젝트의 나머지 활동에도 퍼져나가야 한다.
구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래밍과 같은 모델링 패러다임을 지원하는 
소프트웨어 개발 도구와 언어가 필요하다.

• 단일 모델은 오류가 일어날 확률을 줄인다. 이는 이제 설계가 주의깊게 고려한 모델의 직접적인 결과물이기 때문
• 설계와 구현 기법을 활용해 코드가 모델을 효과적으로 표현할 수 있게 해야 한다
• 지식 탐구자는 모델의 선택사항들을 조사하고 그것들을 정제해서 실제적인 소프트웨어의 구성요소로 만든다
• 개발은 모델, 설계, 코드를 단일한 활동으로 정제하는 반복적인 과정

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

• MODEL-DRIVEN DESIGN이 성과를 내려면 인간이 오차 범위 내에서 정확하게 모델과 구현이 직접적으로 대응해야만 한다

• 이를 가능하게 하려면 개념에 직접적으로 대응되도록 소프트웨어 도구가 뒷받침되는 모델링 패러다임 내에서 업무를 하는 것이 필수적

• 그림 3.1

  

• 객체지향 프로그래밍은 모델링 패러다임에 근거하고 모델의 구성요소에 대한 구현을 제공하기 때문에 효과적

• 객체 설계에서의 진정한 도약은 코드가 모델의 개념을 표현할 때만 나온다

• 프롤로그(Prolog)라는 언어는 MODEL-DRIVEN DESIGN에 잘 어울린다