DDD (Domain Driven Design)

                                                                   Eternity(http://aeternum.egloos.com/)

분석/설계 미신

소프트웨어 개발 분야는 다른 성숙한 분야에 비해 상대적으로 그 역사가 짧기 때문에 다양한 분야로부터 메타포를 받아 들였다. 가장 대표적인 것이 제조(manufacturing)와 건축(architecture)이며 두 분야는 소프트웨어 개발에 필요한 어휘와 개념을 제공하기도 했지만 개발 프로세스와 사람이라는 관점에서 부정적인 영향을 끼치기도 했다.

제조 메타포에서 숙련된 엔지니어는 UML과 같은 표기법을 사용해서 구현에 필요한 설계 도면을 작성하고 덜 숙련된 노동자는 기계적으로 다이어그램에 명시된 요소를 프로그램 명령문으로 변환한다. 프로그래밍이란 설계 문서를 프로그램으로 변환시키는 것이므로 이 과정에서 오류를 줄이기 위해 자동으로 코드를 생성해주는 기법을 적용시키는 겂이 효과적이다. 과연 그럴까?

제조 메타포를 기반으로 한 역할 분리는 근본적으로 두 가지 오류를 범하고 있다. 첫 번째 오류는 설계자와 구현자 간의 차이를 고려하지 않고 기계적으로 설계를 구현으로 변환할 수 있다는 믿음을 전제로 한다는 점이다. 유사한 경험과 경력을 가진 사람들 간에도 커뮤니케이션이 불완전해지는 경우를 자주 보게 된다. 하물며 서로 다른 역할과 경험을 기반으로 하는 두 계층 간에 다이어그램과 문서 중심의 커뮤니케이션이 가능하다는 근거 없는 믿음은 어디에서 기인한 것일까?

이는 설계자가 코더보다 똑똑하거나 숙련된 사람이어야 하는가에 대한 문제가 아니라, 그들이 같은 경험과 기본 단위를 가지고 있는가에 대한 문제이다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

제조 메타포의 두 번째 오류는 구현 전에 설계를 완성시키는 것이 가능하다고 가정하는 점이다.
그러나 실제로는 개략적인 설계를 구현으로 옮기는 도중에 전체 구조에 대한 가장 중요한 통찰을 얻게 된다. 구현 전에 대략적인 설계를 동결시키는 방식은 구현으로부터 얻게 되는 피드백을 원천적으로 차단하는 역효과를 가져온다. 따라서 UML과 같은 표기법을 사용해서 설계를 동결시키고 이를 구현자에게 전달해서 프로그램을 구현하도록 하거나 코드를 생성하는 아이디어는 소프트웨어 개발에는 적합하지 않다. (즉 구현과 분리된 설계는 의미가 없다.)

우리는 분석 모델, 설계 모델, 구현 모델이 서로 달라야 한다는 오랜 미신 속에 살아 왔다. 이론적으로 분석 모델은 해결 방법에 대한 언급 없이 문제 도메인을 설명하는 모델이다.

분석 모델이 완성되면 이를 바탕으로 기술적인 관점에서 솔루션을 서술하는 설계 모델이 만들어 진다. 프로그래머는 이렇게 만들어진 청사진을 프로그래밍 언어를 사용하여 컴퓨터가 이해할 수 있는 명령어로 변환한다.

그러나 분석 모델, 설계 모델, 구현 모델을 명확하게 구분하는 것은 가능하지도 않을 뿐만 아니라 오히려 소프트웨어의 품질에 악영향을 미친다. 짂실로 우리가 원하는 것은 소프트웨어의 영혼에 영광을 안겨줄 분석과 설계와 구현의 삼위일체론이다.

                                                                                    -- continue.....