모델과 구현의 관계

소프트웨어 개발 프로젝트의 맥락에 한정해서 생각해도 모델은 다양한 형태로 나타나고 여러 역할을 수행한다.

도메인 주도 설계에서는 초기 분석 단계에 도움될 뿐 아니라 설계의 기반이 되는 모델이 필요하다. 따라서 적절한 모델링 접근법을 알아야할 필요가 있다.

Model-Driven Design

코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 결국엔 모델과 코드가 서로 대응하는 관계가 된다.

여러 복잡한 프로젝트에서 도메인 모델을 시도하더라도 모델과 코드를 긴밀하게 연결하지는 못 한다. 따라서 모델을 정성들여 만들더라도 설계가 올바르다는 것을 보장하는 것은 아니며 코드와도 분리될 여지가 있다.

모델과 코드 간의 연결이 끊어지는 경우는 다양하고 종종 의도적으로 그렇게 할 때도 있다. 여러 설계 방법론에서는 분석 모델(Analysis Model)의 필요성을 지지한다.

분석 모델은 업무 도메인의 개념만을 체계화하고자 해당 업무 도메인을 분석한 결과물이다. 오로지 이해하기 위한 수단으로만 간주되며 구현 관심사와 섞일 경우 오히려 혼란만 초해하는 것으로 여겨진다.

이러한 분석 모델은 설계상의 쟁점들을 염두에 두고 만들어진 것이 아니라서 모델과 설계의 연결을 분석 모델로 진행한다는 것은 매우 비현실적일 가능성이 높다.

분석 모델을 통해 지식 탐구의 과정을 거칠 수는 있겠지만, 설계를 위해 새로이 추상화를 할 땐 결국 지식 탐구의 성과 중 대부분이 필요없는 것으로 남게될 수 있다. 따라서 비용 대비 효율이 높지 않다.

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

설계에서는 대상 배포 환경에서 효율적으로 수행되고 애플리케이션에서 다뤄야 할 문제를 올바르게 해결해 줄 수 있는 구성요소를 기술해야 하며, 이러한 구성요소는 프로젝트에서 사용 중인 프로그래밍 도구로 구현할 수 있어야 한다.

MODEL-DRIVEN DESIGN에서는 양쪽 모두의 목적을 달성하는 단일 모델을 찾기 위해 분석 모델과 설계를 나누는 이분법은 채택하지 않는다. 순수하게 기술적인 쟁점은 배제함으로써 설계상의 각 객체는 모델에서 기술한 개념적 역할을 수행하게 된다.

모델과 설계를 연계하는 것이 실용적인 이유는 도메인을 추상화하는 방법과 애플리케이션의 문제를 해결할 수 있는 설계 방법에 여러가지가 있기 때문이다. 연계하는 과정에서 기술적 고려사항 탓에 분석이 심각하게 타협된 상태에 놓여서는 안 되며, 동시에 도메인 아이디어는 반영하지만 소프트웨어 설계 원칙은 따르지 않은 서툰 설계를 받아들여서도 안 된다.

이 두 가지 관점에서 효과적인 모델이 필요하기 때문에 만약 어떠한 모델이 구현에 대해 비현실적으로 보인다면 새로운 모델을 찾아내야만 한다. 반대로 모델이 도메인의 핵심 개념을 충실하게 표현하지 않는 때도 새로운 모델을 찾아내야만 한다.

정리하자면,

• 소프트웨어 시스템의 일부를 설계할 때는 도메인 모델을 있는 그대로 반영해서 설계와 모델의 대응을 분명하게 하라.
• 모델을 재검토해서 더욱 자연스럽게 소프트웨어로 구현될 수 있도록 수정하라.
• 분석과 설계의 두 가지 측면을 충분히 만족하는 하나의 모델을 만들어라.
• 모델로부터 설계와 기본적인 책임 할당에 사용한 용어를 도출하라.
• 코드와 모델의 대응으로 코드의 변경이 곧 모델의 변경으로 이어지고, 그 반대도 가능하도록 하라.
• 구현을 모델과 그대로 묶으려면 보통 객체지향 프로그래밍과 같은 모델링 패러다임을 지원하는 소프트웨어 개발 도구와 언어가 필요하다.