도메인 주도 설계 - 15. 디스틸레이션

백근영·2020년 2월 26일
0
post-thumbnail

디스틸레이션(distilation)은 혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정이다. distilation이라는 단어의 사전적 의미처럼 도메인 모델은 여러 번의 증류 과정을 거쳐 중요한 부분과 중요하지 않은 부분을 명확히 구분할 수 있게 된다.

CORE DOMAIN (핵심 도메인)

디스틸레이션은 결국 CORE DOMAIN을 찾아나가는 과정이다. 우리는 도메인 모델의 각 부분에 우선순위를 매겨 도메인의 핵심적인 측면을 구분해야 한다. 이 핵심은 다루기 수월해야 하고 애플리케이션의 기능성을 만들어내는 데 충분히 활용할 수 있어야 한다.

모델을 요약하라. CORE DOMAIN을 찾아 그것을 지원하는 다수의 모델과코드로부터 쉽게 구별할 수 있는 수단을 제공하라. 가장 가치 있고 전문화된 개념을 부각시켜라. CORE를 작게 만들어라.

GENERIC SUBDOMAIN (일반 하위 도메인)

일반 하위 도메인이란 현재 설계하고 있는 도메인 모델에 특화되어 있지 않은 일반적인 도메인을 뜻한다. 이러한 일반 하위 도메인은 핵심 도메인과 명확히 분리될 필요가 있으며, 일반 하위 도메인에는 핵심 도메인보다 낮은 우선순위가 매겨져야 한다. 일반 하위 도메인에 대해서는 기성 솔루션이나 공표된 모델을 고려해볼 필요가 있다.

일반화 != 재사용 가능성

일반 하위 도메인을 찾아 핵심 도메인과 분리시킬 필요는 있지만, 그것이 일반 하위 도메인이 재사용 가능성을 갖게 만들라는 뜻은 아니다. 우리가 일반 하위 도메인을 따로 분리시키려는 목적은 핵심 도메인을 명확히 드러내기 위함이지, 코드의 중복을 없애기 위함이 아니다. 따라서 일반 하위 도메인을 분리할 때 완벽한 일반성을 갖추도록 고민하지는 않아도 된다.

DOMAIN VISION STATEMENT (도메인 비전 선언문)

DOMAIN VISION STATEMENT는 애플리케이션이 목표로 해야 할 가치를 선언한 글이다. 이 DOMAIN VISION STATEMENT는 팀원 전원이 공유함으로써 개발의 모든 국면에 걸쳐 자원 할당과 모델링 선택을 안내하고 팀원들을 교육할 때 직접적으로 활용할 수 있다.

DOMAIN VISION STATEMENT에서는 CORE DOMAIN을 짧게 기술하고 그것이 가져올 가치에 해당하는 '가치 제안'을 작성해야 한다. 이 도메인 모델과 다른 것과 구별하는 데 도움이 되지 않는 측면은 무시하고, 도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지 보여야 한다.

올바른 DOMAIN VISION STATEMENT

반도체 공장 자동화

"도메인 모델은 필요한 감사 추적을 제공하고 자동화된 제품 전달이 지원될 수 있는 방식으로 반도체 생산 공정상의 재료와 장비 상태를 표현할 것이다.

모델은 프로세스에 필요한 인력 자원을 포함하지는 않지만 공정 방법을 내려 받아 선택적인 프로세스 자동화가 가능해야 한다.

인간 관리자는 공장 상태 표시를 쉽게 이해할 수 있어 더 심층적인 통찰력을 주고 더 나은 의사결정을 내릴 수 있게 지원해야 한다."

올바르지 않은 DOMAIN VISION STATEMENT

반도체 공장 자동화

"소프트웨어는 서블릿을 통해 웹에서 접근할 수 있으면서 다른 인터페이스도 쓸 수 있는 구조여야 한다.

사내 개발과 유지보수 비용을 피하고 외부 전문 지식의 수용을 최대화하고자 가능한 한 산업 표준 기술을 사용해야 한다. 아파치 웹 서버와 같은 오픈소스 솔루션이 선호된다."

HILIGHTED CORE (강조된 핵심)

앞서 말한 GENERIC SUBDOMAIN과 DOMAIN VISION STATEMENT 등의 방법으로 CORE DOMAIN을 파악할 수 있게 되었다고는 해도, CORE DOMAIN의 구성요소를 식별하는 것은 전혀 예측할 수 없는 개별 해석의 몫으로 남아있다. 그래서 우리는 다음과 같은 방법을 사용해서 모델의 어떤 구성 요소가 CORE DOMAIN에 속하는지 명시적으로 강조할 필요가 있다.

디스틸레이션 문서

CORE DOAMIN과 CORE DOMAIN의 구성요소 사이에서 일어나는 상호작용을 기술하는 매우 간결한 문서를 디스틸레이션 문서라고 한다. 디스틸레이션 문서는 완전한 설계 문서가 아니다. 단지 최소주의적인 진입점으로서 CORE의 윤곽을 드러내고 설명하며 특정 부분을 좀더 면밀하게 조사하는 이유를 제기한다.

표시된 CORE

HILIGHTED CORE는 꼭 문서의 형태로 존재할 필요는 없다. 객체 다이어그램 내에서 CORE를 명시적으로 표시할 수도 있고, Doc(ex) JavaDoc, PHPDoc, etc ..)으로 작성한 주석이나 개발환경에서 제공하는 도구를 사용할 수도 있다.

모델의 주요 저장소 안에 있는 CORE DOMAIN의 구성요소에 대해 그것의 역할을 설명하려 하지 않고 표시하는 것만으로도 큰 이득을 취할 수 있다. 개발자가 힘들이지 않고도 CORE의 안과 밖을 알 수 있게 될 것이다.

COHESIVE MECHANISM

COHESIVE MECHANISM의 핵심은 '무엇'과 '어떻게'를 분리하는 것이다. 종종 도메인 모델에서 굉장히 중요한 개념적인 '무엇'이 기계적인 '어떻게'에 가려지곤 한다. 이 '어떻게'를 담당하고 있는 기계적인 매커니즘을 별도의 경량 프레임워크로 분할함으로써 우리는 CORE DOMAIN에 개념적으로 더욱 집중할 수 있게 된다.

예시 : 조직도 모델

조직도 모델을 필요로 하는 프로젝트에서 프로젝트 요구사항을 '어떻게' 만족시킬 것인지에 대한 해답으로 그래프라는 응집력 있는 매커니즘을 생각해볼 수 있다. 그래프라는 개념을 프로젝트에 도입함으로써 CORE DOMAIN의 개념적 측면에 더 명확하게 접근할 수 있었을 것이다. '어떻게'에 관한 부분이 그래프라는 매커니즘으로 분리되지 않고 도메인 모델 내에 암시적으로 혼합되어 있었다면 CORE DOMAIN은 본질을 잃고 복잡하고 혼란스러워졌을 것이다.

profile
서울대학교 컴퓨터공학부 github.com/BaekGeunYoung

0개의 댓글