Domain Driven Design/Eric Evance - 3. Binding Model and Implementation

만약 소프트웨어 디자인이 도메인 모델과 매핑되지 않는다면, 그 모델은 가치가 없거나 소프트웨어의 정확성이 의심된다. 동시에 모델과 디자인 기능간의 매핑의 복잡성은 이해하기 어렵고 디자인 변경에 대한 유지관리가 어렵다. 분석과 디자인 사이에 치명적인 격차가 발생하여 각각의 활동으로 부터 얻은 인사이트가 서로 영향을 미치지 못하는 상태가 발생한다.  

MODEL-DRIVEN DESIGN은 해석 모델과 디자인의 이분법을 버리고 두 가지 목적을 모두 충족하는 단일 모델을 찾습니다. 순전히 기술적인 문제를 제외하고 디자인의 각 개체는 모델에 설명된 개념적 역할을 합니다. 이것은 두 개의 완전히 다른 목표를 충족해야 하기 때문에 우리에게 더 부담지우긴 합니다. 

매핑이 명확하게 도메인 모델을 문자 그대로 소프트웨어 시스템에 반영하여 설계하십시오. 도메인에 대한 더 깊은 통찰력을 반영하기위해 모델을 재확인하고 소프트웨어에 보다 자연스럽게 구현되도록 수정하십시오. 강력한 UBIQUITOUS LANGUAGE를 지원하는 것 외에도 두 가지 목적을 모두 잘 수행하는 단일 모델이 필요합니다. 

설계에 사용된 용어와 기본 책임 할당을 모델에서 가져옵니다. 코드는 모델의 표현이 되므로 코드의 변경은 모델의 변경이 될 수 있습니다. 이 영향은 프로젝트의 나머지 활동에 전파되어야 합니다. 

구현을 모델에 결합시키려면 일반적으로 객체 지향 프로그래밍과 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요합니다.

코드를 작성하는 사람들이 모델에 대한 책임을 느끼지 않거나 모델을 애플리케이션에서 작동하게 만드는 방법을 이해하지 못한다면 모델은 소프트웨어와 아무 관련이 없습니다. 개발자가 코드 변경이 모델을 변경한다는 사실을 깨닫지 못한다면 리팩토링은 모델을 강화하기보다는 약화시킬 것입니다. 

한편, 모델러가 구현 과정으로부터 분리된다면 구현의 제약사항들에 대해 느끼지 못할수 있습니다. 모델이 효과적인 구현을 지원하고 주요 도메인 지식을 추상화한다는 MODEL-DRIVEN DESIGN의 기본 제약이 상당량 없어지면서 결과 모델이 비실용적이 됩니다. 마지막으로, 분업이 MODEL-DRIVEN DESIGN을 코딩하는데 있어 디테일을 전달하는 종류의 협업을 방해한다면 숙련된 디자이너의 지식과 기술은 다른 개발자에게 이전되지 않습니다.

모델에 기여하는 모든 기술 담당자는 프로젝트에서 수행하는 주요 역할에 관계없이 코드를 만지는 데 시간을 할애해야 합니다. 코드 변경을 담당하는 사람은 누구나 코드를 통해 모델을 표현하는 방법을 배워야 합니다. 모든 개발자는 모델에 대한 일정 수준의 토론에 참여해야 하며 도메인 전문가와 접촉해야 합니다. 다양한 방식으로 기여하는 사람들은 코드를 만지는 사람들을 의식적으로 참여하여 모델 아이디어를 역동적으로 교환해야 합니다.