DDD - Domin Driven Design이란?

소프트웨어에서 도메인이란 소프트웨어에서 실제 해결해야될 문제점을 의미한다. 도메인에 대한 이해없이 복잡한 소프트웨어를 개발하는 것은 불가능하다. 그렇다면 누가 가장 많은 도메인 지식을 가지고 있나? 그것은 소프트웨어 아키텍트도 아니고 비즈니스 컨설턴트도 아니다. 개발자는 더더욱 아니고. 정답은 현업 혹은 사용자이다. 그들은 비즈니스를 가장 잘 이해하고 있는 사람들이다.

소프트웨어 프로젝트를 첨 시작할 때 도메인에 초첨을 맞춰야 한다. 가장 좋은 방법은 도메인을 반영한 소프트웨어를 설계하는 것이다. 소프트웨어는 코어 컨셉과 도메인 요소를 포함해야 하며 둘의 관계를 반영해야 한다. 해당 소프트웨어에 대한 지식이 없는 사람도 도메인 모델의 코드를 읽으면 해당 도메인에 대해 알 수 있어야 한다.

도메인을 추상화하고 도메인 전문가와 많이 대화를 해야 한다. 추상화는 도메인의 모델이다. 모델은 설계와 개발 단계에 전달되어야 할 대상 도메인의 내부적인 표현이다. 우리는 정보를 조직하고, 시스템화하고, 더 작게 분할하고 로지컬한 모듈로 합치기도 한다. 이것이 우리의 도전이다. 무엇을 버리고 무엇을 지켜야 할까? 뱅킹 솔루션에서 고객 정보 중 주소는 유지해야 하지만 고객의 눈색깔은 필요없다. 모델을 가지고 도메인 전문가, 동료 설계자 및 개발자와 많이 대화해야 한다. 혼자서 소프트웨어의 모든 부분을 개발할 수 없다. 지식과 정보는 공유되어야 한다.

모델로 표현이 되었다면, 코드 디자인을 할 수 있다. 코드 디자인은 소프트웨어 디자인과 다르다. 소프트웨어 디자인을 집을 짓기 위한 설계에 비유 하자면 청사진이 되고, 코드 디자인은 벽을 어떤 색으로 칠할 것인가 같은 세밀한 작업이 된다. 코드 디자인의 실수는 쉽게 고칠 수 있지만, 소프트웨어 디자인의 오류는 고치기 위해서 많은 비용이 소모된다. 좋은 코드 디자인 없이 좋은 제품을 만들 수 없다.

소프트웨어 디자인에는 다른 접근법들이 존재한다. 첫번째는 워터폴 디자인 방식이다. 이 방법은 몇가지 단계를 포함한다. 비즈니스 전문가가 요구사항을 내고, 분석가가 요구사항을 기반으로 한 모델을 만든다. 모델은 개발자에게 전달되고 코딩을 시작한다. 지식이 단방향으로 전달된다. 소프트웨어 디자인의 전통적인 방식이다. 이 방식의 가장 큰 문제점은 분석가가 비즈니스 전문가에게 개발자가 분석가에게 피드백을 전달하기 어렵다는 점이다.

다른 방식은 XP로 알려진 애자일 방식이다. 초기에 도메인의 모든 영향도를 커버하는 완성된 모델을 만드는 것은 불가능하다. 그리고 누구도 초기 디자인의 오류나 사이드 이펙트를 예측할 수 없다. 애자일 옹호자들은 초기에 디자인하는 것을 반대한다. 유연성에 최고 가치를 두고, 현업 및 고객 참여시키고 수많은 리팩토링을 수행하면서 반복적으로 개발한다. 반복적인 개발과정을 통해서 개발팀은 도메인에 대한 이해를 증대시키고 고객 요구에 부합시킬때까지 개발을 반복한다.

애자일도 물론 문제점과 한계를 가지고 있다. SOLID 디자인 원칙없는 리팩토링은 이해하거나 변경하기 힘든 코드를 생산해낸다. 워터폴은 종종 오버 엔지니어링를 유발하지만 애자일은 기능 개발에 초점이 되어 전체적인 설계에 실수가 발생할 수 있다.

DDD는 설계와 개발이 조화되어 있다. 좋은 솔루션을 만들기 위해 개발과 설계가 어떻게 상호작용하는지 알게 될 것이다. 좋은 설계는 개발을 가속화시키고 개발로 부터 발생한 피드백은 설계를 더 좋게 만들 것이다.

출처 : Domain Driven Design Quickly