DDD - Model Driven Design

이전에 우리는 비즈니스 도메인 중심의 소프트웨어 개발 방법에 대한 중요성에 대해서 살펴보았다. 모델을 생성하기 위해서 가장 중요한 점은 도메인에 중심을 두어야 하며 도메인의 핵심적인 요소를 반영해야 한다는 것이다. 모델링 단계의 주목적은 좋은 모델을 만드는 것이다. 그리고 다음 단계가 코드로 모델을 구현하는 것이다. 소프트웨어 개발 프로세스에서  이 단계들은 똑같이 중요하다. 

소프트웨어 분석가와 비즈니스 도메인 전문가가 도메인의 기초적인 요소와 그들간의 관계를 강조하고, 정확한 모델을 생성하기 위해 몇달동안 협업을 하면 정밀한 도메인 캡쳐를 가지게 된다. 그러면 모델은 개발자에게 전달된다. 개발자는 모델을 살펴보았을 때, 몇몇의 관계와 컨셉이 코드로 표현하기에 적정하지 않다는 것을 발견하게 된다. 그러면 개발자는 모델의 아이디어를 차용해서 자신만은 설계를 하게 된다. 개발 프로세스가 진행될 수록 많은 클래스들이 코드에 추가되고 원본 모델은 쪼개지고 확장될 것이다. 좋은 결과를 확신할 수 없다. 쉽게 확장가능 할 것인가? 쉽게 유지보수 할 수 있을 것인가?

어떤 도메인은 많은 모델로 표현되고, 어떤 모델은 다양한 방법으로 코드에 표현된다. 각 특정한 문제에 대한 해결책은 하나 이상일 수 있다. 어떤 것을 선택할 것인가? 정확한 모델을 산출했다고 해서 바로 코드로 표현할 수 있는 것은 아니다. 아마도 그것은 소프트웨어 설계 원칙에 따라 구현은 쪼개질 것이다. 가장 중요한 점은 쉽게 정확하게 코드에 모델을 표현하는 것이다. 모델을 코드로 변경하기 위한 접근 방법은 어떠한 것일까?

한가지 추천하는 디자인 기법은 분석 모델(analysis model)이다. 분석 모델은 비즈니스 도메인 분석의 결과가 소프트웨어 구현에 사용될 모델의 결과를 고려하지 않는 것이다. 모델은 도메인을 이해하기 위해서 사용된다. 이러한 접근의 가장 중요한 단점은 분석자가 그들의 모델의 오염과 복잡해지는 것을 예측할 수 없다는 것이다. 매우 중요한 내용과  구현중에 나타날 수도 있다. 그럴 경우 모델은 신뢰할 수 없게 된다. 개발자는 모델을 생성할 때 고려되지 않은 실제 문제를 해결하기위해 디자인의 변경할 때 자신만의 결정을 강요받게 된다. 만약 분석가와 분리되서 일을 하게 된다면, 모델은 설계자에게 전달되고, 몇가지 도메인과 모델에 대한 지식은 사라져버릴 수 있다. 모델은 다이어그램이나 글로 표현되지만 설계자는 모델의 전체 의미를 잘 이해할 수 없을 수도 있다. 모델의 상세한 내용을 다이어그램으로 표현하는 것은 어렵기 때문이다. 개발자는 더더욱 그것을 알아내는데 힘들 것이다. 

분석가는 클로즈드 미팅을 도메인에 대해 많은 지식을 공유할 것이고, 모델을 생성할 때, 고려해야할 만한 모든 포함하고 문서화해서 개발자 한테 전달할 것이다. 만약 이 경우 개발자가 분석 미팅에 참여한다면 더 생산적이면서 도메인과 모델에 대한 명백하고, 완전한 뷰를 가질 수 있을 것이다.  더 좋은 접근 방법은 도메인 모델링과 설계를 같이 하는 것이다. 개발자는 모델링 프로세스에 참여하여 소프트웨어로 표현할때 주요한 아이디어가 모델에 반영될 수 있을 것이다. 

OOP는 모델을 구현하기에 적합하다. 같은 페러다임을 기반으로 하고 있기 떄문이다. OOP는 객체의 클래스를 제공한다. 이는 객체와의 관계, 그들간의 메시징을 표현하는데 용이하다. OOP는 모델 오브젝트와 그들의 관계를 직접적으로 표현할 수 있다.

The Building Blocks Of A Model-Driven Design

모델기반 설계시 가장 중요한 패턴에 대해서 알아보자. 이러한 패턴의 목적은 DDD의 소프트웨어 설계 관점을 오브젝트 모델링으로 주요 요소를 표현하기 위함이다.