(모델과 구현의 결합)

개발자가 응용 프로그램을 구현하기 시작했을 때, 인간 분석가가 탐색할 수 있지만 연관성의 얽힘이 트랜잭션 무결성으로 조작될 수 있는 저장 가능하고, 검색 가능한 단위로 변환되지 않았음을 빠르게 발견했다.

이 프로젝트는 객체 데이터베이스를 사용하고 있었기 때문에 개발자는 객체를 관계형 테이블로 맵핑해야 하는 어려움에 직면할 필요가 없었다. 기본적인 수준에서 모델은 구현 지침을 제공하지 않았다.

모델이 "완벽"했기 때문에, 기술 분석가와 비즈니스 전문가 사이에 광범위한 협업의 결과로, 개발자들은 개념 기반 객체가 설계의 기초가 될 수 없다는 결론에 도달했다. 그래서 개발자들은 ad hoc design(즉석 설계)을 개발하기 시작했다. 그 디자인은 데이터 저장을 위해서 약간의 동일한 클래스 이름(class names)과 속성(attributes)을 사용했지만, 기존 모델이나 다른 모델을 기반으로 하지 않았다.

프로젝트는 도메인 모델을 가졌지만, 직접적으로 실행중인 소프트웨어 개발에 도움이 되지 않는다면, 종이상의 모델이 무엇이 좋은가?

코드를 밑에 있는 모델과 밀접하게 연관시키는 것은 코드에 의미를 주고, 모델을 적합하게 만든다.

원인이 무엇이건 간에, 설계의 기초에서 개념이 결여된 소프트웨어는 기껏해야 동작을 설명하지 않고 유용한 어떤 것을 행하는 메커니즘에 불과하다.

설계, 혹은 설계의 일부 중심 부분이 도메인 모델과 맵핑되지 않으면, 모델은 거의 가치가 없고 소프트웨어의 정확성이 의심된다. 동시에, 모델과 설계 기능 사이에 복잡한 맵핑이 이해하기 어렵고, 실제로 디자인 변경에 따라 유지관리가 불가능하다.

분석과 디자인 사이에 치명적인 격차가 발생하기 때문에 각 활동에서 얻은 통찰력은 다른 활동으로 유입되지 않는다.

Model-Driven Design은 분석 모델과 디자인의 이분법을 폐지하고, 두가지 목적을 모두 제공하는 단일 모델을 찾는다. 순수하게 기술적인 문제를 제외하면, 디자인의 개별 객체는 모델을 설명하는 개념적인 역할을 수행한다.

이것은 두 가지 다른 목표를 달성해야 하기 때문에 선택한 모델을 더 많이 요구한다.

모델이 구현에 대해 현실적이지 않거나 도메인의 주요 개념에 대해 충실하게 표현하지 못하면 새로운 것을 찾아야만 한다. 도멜링과 디자인 과정은 하나의 반복되는 고리(single iternative loop)가 된다.

매우 문자 그대로의 방식으로 도메인 모델을 반영하기 위해서 소프트웨어 시스템의 일부를 디자인하므로 맵핑은 명확해야 한다. 모델을 재방문하여 소프트웨어에 더 자연스럽게 구현되게 수정하라. 심지어 도메인에 대한 더 깊은 인사이트(insight)를 반영하도록 할 때에도 마찬가지이다.

강력한 Ubiquitous Language를 지원하는 것 이외에도 두 가지 목적을 모두 제공하는 단일 모델을 요구하라.

설계에 사용된 모델과 용어로 기본적인 책임(responsibility) 할당을 그려라. 코드는 모델의 표현이므로, 코드의 변경은 모델을 변경하게 될 것이다. 따라서 그 효과는 프로젝트의 나머지 활동에 영향을 미친다.

모델에 구현을 밀접하게 묶기 위해서는 일반적으로 OOP(Object-Oriented Programming)와 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어를 필요로 한다.

단일 모델(single model)은 설계가 신중하게 고려된 모델의 직접적인 파생물이기 때문에 오류 가능성을 줄여 준다.

설계와 코드 그 자체에서도 모델의 의사소통 능력을 가지고 있다.

코드 작성하는 사람이 모델에 대한 책임감을 느끼지 않는다면, 혹은 어떻게 어플리케이션에서 모델이 동작하도록 하는지를 이해하지 못한다면, 모델은 소프트웨어와 아무런 관련이 없다. 개발자가 코드 변경이 모델을 변경하는 것을 깨닫지 못한다면, 리팩토링은 모델을 강화하기보다 약화시킬 것이다. 모델러가 구현 프로세스와 분리되어 있는 동안, 구현에 있어서 제약 사항에 대한 느낌을 결코 얻을 수 없거나 빨리 잃어버릴 것이다. Model-Driven Design의 기본적인 제약 사항-모델이 구현을 효과적으로 지원하고, 핵심 도메인 지식을 추상화한다는 것-은 반만 이루어지게 되고, 모델의 결과는 비현실적이 될 것이다. 마지막으로 업무의 분리가 Model-Driven Design 코딩의 미묘함을 전달하는 협업을 방해한다면, 경험있는 설계자의 지식과 스킬이 다른 개발자들에게 전달되지 않을 것이다.

실무 모델러(hands-on modeler)가 필요하다는 것은 팀 구성원이 특별한 역할을 할 수 없다는 것을 의미하는 것은 아니다. 모든 Agile 프로세스에서, Extreme Programming을 포함하여, 팀 구성원들의 역할을 정의하고, 다른 일상적인 전문화는 일반적으로 나타난다. 문제는 Model-Driven Design에서 밀접하게 연관되어 있는 모델링과 구현을 2개의 업무로 분리할 때 발생한다.

모든 설계에 있어서 효과는 잘 나누어진 설계(fine-grained design)와 구현 의사 결정의 균등함과 일관성에 매우 민감하다. Model-Driven Design과 함께, 코드의 일부분은 모델을 표현하고, 코드의 변경은 모델을 변경한다. 다른 사람이 좋아하든, 그렇지 않든지 간에, 프로그래머는 모델러이다. 따라서, 프로그래머가 훌륭한 모델링 업무를 하도록 프로젝트를 설정하는 것이 더 좋다.

프로젝트에서 주요 역할이 무엇이건 간에, 모델에 기여하는 어떤 기술적인 사람이라도 코드를 다루는데 시간을 보내야 한다. 코드를 변경하는 사람이 누구이건 간에 코드를 통해 모델을 표현하는 방법을 배워야 한다. 모든 개발자는 모델에 대한 어느 수준의 논의에 포함되어야 하고, 도메인 전문가와 함께 해야 한다. 다른 방식으로 기여하는 사람들은 Ubiquitous Language를 통해 모델에 대한 아이디어를 동적으로 교환하여 코드를 다루는 사람으로 의식적으로 참여해야 한다.

Domain-Driven Design은 어플리케이션의 문제를 해결하기 위해 모델이 동적하도록 한다.

Model-Driven Design은 모델과 구현을 긴밀하게 연결한다.

Ubiquitous Language는 모든 정보가 개발자와 도메인 전문가, 소프트웨어 사이에 흐르게 하는 채널이다.