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

소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의
대응을 분명하게 하라. 또한 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있게
수정하라. 도메인에 관한 더욱 심층적인 통찰력을 반영하려 할대도 마찬가지다. 이렇듯 견고한 
UBIQUITOUS LANGUAGE 를 지원하는 것과 더불어 분석과 설계의 두가지 측면을 충분히
만족하는 단 하나의 모델을 만들어내야 한다. 

모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출하라. 코드를 작성할때 그러한
용어를 사용하면 코드가 모델을 표현할 것이 되고, 코드의 변경이 곧 모델의 변경으로 이어질 수 
있다. 그 효과는 프로젝트의 나머지 활동에도 퍼져나가야 한다.

구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래jjㅕㅕuu밍과 같은 모델링 패러다임을 지원하는 
소프트웨어 개발 도구와 언어가 필요하다. 

설계가 사용자와 도메인 전문가의 기본적인 관심사를 반영하는 모델에 기반을 두면 설계의 골
격이 다른 설계 접근법에 비해 더 큰 범위에 걸쳐 사용자에게 드러날 수 있다. 모델이 드러나면
사용자가 소프트웨어의 잠재력을 좀더 많이 접하게 되어 일관성 있고 예상 가능한 행위가 나타
날 것이다.

코드를 작성하는 사람이 모델에 책임을 느끼지 못하거나 애플리케이션을 대상으로 모델이 동
작하게 만드는 법을 모른다면 그 모델은 소프트웨어와 무관해진다. 코드의 변경이 곧 모델의 변
경이라는 점을 개발자가 인식하지 못하면 리팩터링은 모델을 강화하기보다는 약화시킬 것이다.
한편으로 모델러가 구현 프로세스와 분리돼 있을 경우, 구현상의 제약조건을 감안하는 능력을
결코 갖추지 못하거나 금방 읽어버릴 것이다. 모델이 효과적인 구현을 뒷받침하고 핵심 도메인 지
식을 추상화한다는MODEL-DRIVEN DESIGN의 기본적인 제약조건은 절반쭘 사라지고, 결
과로 나타는 모델은 실용적이지 못할 것이다. 결국 MODEL-DRIVEN DESIGN 을 코드로 만
드는 과정의 미묘한 사항들은 협업을 통해 알 수 있는데, 설계자가 구현을 하지 못해 개발자와 업
무의 단절이 생기면 숙련된 설계자의 지식과 솜씨는 결코 다른 개발자에게 전해지지 못할 것이다.

모델에 기여하는 모든 기술자는 프로젝트 내에서 수행하는 일차적 역할과는 상관없이 코드를
접하는 데 어느 정도 시간을 투자해야만 한다. 코드를 변경하는 책임이 있는 모든 이들은 코드를
통해 모델을 표현하는 법을 반드시 배워야 한다. 모든 개발자는 모델에 관한 일정 수준의 토의에
깊이 관여해야 하고 도메인 전문가와도 접촉해야 한다. 다른 방식으로 모델에 기여하는 사람들은
의식적으로 코드를 접하는 사람들과 UBIQUITOUS LANGUAGE 를 토대로 모델의 아이디어를 나누는 데
적극 참여해야 한다.