model driven design
코드는 그것의 기반이 되는 모델과 긴밀하게 연결되어 있어야 하며, 그러한 코드는 의미를 갖게 된다.
분석을 위한 모델과 설계를 위한 모델
지나치게 이론적이고 분석만을 위한 모델은 실제 설계에 적용하기에 부적합할 것이고 설계만을 위한 모델은 지식 탐구 과정에서 얻은 지식들을 온전히 반영하지 못할 가능성이 높다.
모델 주도 설계에서는 이 분석과 설계 둘 다를 위한 단일 모델을 만드는 것을 목표로 한다.
소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 해야한다. 또한 모델을 재검토해서 더욱 자연스럽게
소프트웨어로 구현될 수 있게 수정해야 한다. 도메인에 관한 더욱 심층적인 통찰력을 반영하려 할 때도 마찬가지다. 이렇듯 견고한 보편 언어를 지원하는 것과 더불어
분석과 설계의 두 가지 측면을 충분히 만족하는 단 하나의 모델을 만드는 것이 모델 주도 설계의 핵심이다. 구현과 모델을 그대로 묶으려면 보통 객체지향 프로그래밍과 같은
모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요하다.
내부 드러내기: 왜 모델이 사용자에게 중요한가
도메인 영역의 지식을 충실히 담고 있는 분석/설계 모델을 소프트웨어 사용자에게 있는 그대로 노출하는 것은 사용자에게 그리 편리하지는 않을 것이다. 하지만 UI에
도메인 모델이 아닌 다른 모델의 환영을 만들려는 시도는 그것이 완벽하지 않을 경우 혼란만을 초래한다.(ex) IE 브라우저의 '즐겨찾기' 모델) 사용자가 편안하게 받아들일 수 있는
범위 내에서 도메인 모델을 있는 그대로 노출하고, 혼란을 일으키는 대안 모델은 제거한다.
hands-on modeler
모델링, 설계, 프로그래밍에 대한 책임을 지나치게 구분하는 것은 model-driven design에 어긋난다. 모델을 만드는 사람, 즉 모델러라고 불리는 사람이 개발의 과정에 참여하지 않게 되면
그 모델은 소프트웨어와 무관해질 수 있다. 코드의 변경이 곧 모델의 변경이라는 점을 개발자가 인식하지 못하면 리팩터링은 모델을 강화하기보단 약화시킬 것이다.
모델러가 구현 프로세스와 분리되어 있을 경우, 모델러는 구현상의 제약조건을 감안하는 능력을 갖추지 못할 것이다. 모델을 코드로 구현하는 과정에서 발생하는 미묘한 사항들은
모델러가 개발자와 직접적으로 협업해야만 알 수 있는 것들이다. model-drvien design에서는 hands-on modeler가 필요하다.
hands-on developer?
꼭 모델러만이 실천적이어야 하는 것은 아닐 것 같다. 모델러에게 '실천적'이란 개발 프로세스에 실천적으로 참여하는 것을 뜻할 것이고, 한편으론 모델링 과정에 적극적으로 관심을 기울이는
개발자의 실천성 또한 중요하다고 생각한다. 이러한 모든 의사소통은 또한 앞서 이야기한 보편 언어로 이루어짐으로써 보편 언어는 설계 및 구현의 전 과정에서 다듬어지며,
보편 언어의 정제는 곧 모델의 발전을 의미한다.
