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

• 디스틸레이션 : 혼합된 요소를 분리해서 값지고 유용한 형태로 본질을 뽑아내는 과정
• 도메인 모델에 대한 디스틸레이션 사항
  1. 팀원들이 시스템의 전체 설계와 해당 설계가 어떻게 함께 조화될지 파악하게끔 돕는다.
  2. UBIQUITOUS LANGUAGE의 일부가 될 수 있게 관리 가능한 크기의 핵심 모델을 식별해서 의사소통을 촉진한다.
  3. 리팩터링을 이끈다.
  4. 가장 중요한 모델 영역의 업무에 초점을 맞춘다.
  5. 아웃소싱, 기성 컴포넌트의 활용, 할당에 관한 의사결정을 돕는다.

 

---

CORE DOMAIN (핵심 도메인)

• CORE DOMAIN은 시스템에서 가장 큰 가치가 더해지는 곳이며, 애플리케이션의 특유하고 중심적인 모델이 구성한다.
• 모델을 요약해서 CORE DOMAIN 찾고, 다수의 모델과 코드로부터 쉽게 구별할 수 있도록 해야한다.
  
  
• CORE 선택
  • 관점에 따라 다른 모델이 CORE DOMAIN으로 선택될 수 있다.
  • 외부 설계 전문가를 고용하기보단 내부의 전문가가 구성원들에게 도메인 설계 기술을 축적하는 것을 돕고 정교한 원칙을 활용하도록 이끄는 것이 좋다. 

---

GENERIC SUBDOMAIN (일반 하위 도메인)

• 부수적인 요소가 CORE DOMAIN을 식별하고 이해하는 일을 어렵게 만들기도 한다.
• 따라서 진행 중인 프로젝트를 위한 것이 아닌 응집력 있는 하위 도메인을 식별해야 한다.
• 하위 도메인에서는 일반화된 모델 요소를 추출해서 별도 MODULE에 배치한다.
• 이러한 GENERIC SUBDOMAIN에 대해서는 기성 솔류션이나 공표된 모델을 고려할 수 있다.
• 일반화가 재사용 가능하다는 의미는 아니다.
  • 모델의 개념을 여러 상황에 적용할 수 있더라도 완벽한 일반성을 갖춘 모델을 개발할 필요는 없다.
  • 그러나 일반 재사용을 목표로 하지 않더라도 일반 개념 범위 내에서 설계를 유지해야 한다.

---

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

• 비전 선언서는 애플리케이션이 조직에 가져올 특정 가치를 기술한다.
• 도메인 모델을 다른 것과 구별하는 데 도움이 되지 않는 측면은 무시하고, 도메인 모델이 다양한 관심사를 충족하고 균형을 이루는지 보여야 한다. 

---

HIGHLIGHTED CORE (강조된 핵심)

• 어떤 모델에서 특별히 중요한 부분을 그것과 구체화한 구현과 함께 표현할 필요가 있다.
• 반드시 모델 자체의 한 부분일 필요는 없으며, 모든 사람이 CORE DOMAIN을 쉽게 알 수 있게 만드는 거라면 어떤 기법도 괜찮다.
• 디스틸레이션 문서
  • HIGHLIGHTED CORE의 한 형태로서 CORE DOMAIN과 CORE의 구성요소 사이에서 일어나는 상호작용을 기술하는 간결한 문서이다.
  • 완전한 설계 문서는 아니지만, CORE의 윤곽을 드러내고 설명하며, 특정 부분을 면밀하게 조사하는 이유를 제기한다.
  • 문서를 별도로 유지했을 때는 다음과 같은 위험요소가 발생할 수 있다.
    1. 문서가 관리되지 않을 수도 있다.
    2. 문서를 아무도 읽지 않을지도 모른다.
    3. 정보의 출처가 늘어남으로써 복잡성을 관통하는 문서 본연의 목적이 무의미해질 수도 있다.
  • 최소주의를 지향하여 중심적인 추상화와 상호작용에 집중하면 이러한 위험요소를 제한할 수 있다.
• 표시된 CORE 
  • 모델의 주요 저장소 안에 있는 CORE DOMAIN의 구성요소에 대해 그것의 역할을 설명하려 하지 않고 표시한다.
  • 객체 다이어그램이나 UML 다이어그램, Java Doc 주석 등 객체 다이어그램이나 UML 다이어그램, Java Doc 주석 등 어떤 기법이든 개발자가 힘들이지 않고도 CORE의 안과 밖을 알아볼 수 있게 한다.
• 프로세스 도구로서의 디스틸레이션 도구
  • 디스틸레이션 문서를 모델 변경의 중요성을 나타내는 실질적인 지표로 사용할 수 있다.
  • 디스틸레이션 문서에 영향을 주는 코드나 모델의 변경은 다른 팀원과의 상의가 필요하다.
  • CORE의 밖이나 디스틸레이션 문서에 포함되지 않은 세부사항은 상의나 통보없이 변경될 수 있다.

---

COHESIVE MECHANISM (응집력 있는 메커니즘)

• 개념적으로 COHESIVE MECHANISM을 별도의 경량 프레임워크로 분할해야 한다.
• INTENTION-REVEALING INTERFACE로 프레임워크의 기능을 노출한다.
• 도메인의 다른 요소들을 해법의 복잡성("어떻게")을 프레임워크에 위임해서 문제("무엇")을 표현하는 데 집중할 수 있다.
  
  
• GENERIC SUBDOMAIN과 COHESIVE MECHANISM
  • GENERIC SUBDOMAIN과 COHESIVE MECHANISM은 모두 CORE DOMAIN의 부담을 더는 데 목적이 있다.
  • GENERIC SUBDOMAIN은 팀이 도메인을 어떻게 바라보는지와 관련된 일부 측면을 나타내는 표현력 있는 모델에 토대를 둔다.
  • COHESIVE MECHANISM은 도메인을 나타내지 않으며, 표현력 있는 모델에서 제기하는 성가신 계산 문제를 해결할 뿐이다.

---

SEGREGATED CORE (분리된 핵심)

• 모든 하위 도메인에 GENERIC SUBDOMAIN을 추출하기는 쉽지 않다.
• 따라서 보조적인 역할로부터 CORE의 개념을 분리되게끔 모델을 리팩토링하고 CORE의 응집력을 강화시켜야 한다.
• GENERIC SUBDOMAIN에 적용한 지침과 같지만 다른 방향에서 유래한다. 애플리케이션의 중심이 되는 응집력 있는 하위 도메인은 식별되어 자체적인 패키지로 분할될 수 있다.
  
  
• SEGREGATED CORE로 리팩터링하는 단계는 다음과 같다.
  1. CORE 하위 도메인을 식별한다.
  2. 새로운 MODULE로 관련 클래스를 옮긴다. 이때 MODULE의 이름은 관련 개념에 따라 짓는다.
  3. 개념을 직접적으로 표현하지 않는 서버 데이터와 기능으로 코드를 리팩터링 한다. CORE 하위 도메인의 불순물을 제거하고 그곳에서 다른 패키지를 참조하는 바를 명시적인 상태로 만드는 데 집중한다.
  4. 새로생긴 SEGREGATED CORE MODULE의 관계와 상호작용을 더욱 단순하고 전달력있게 만든다.
  5. SEGREGATED CORE가 완전해질 때까지 또 다른 CORE 하위 도메인을 대상으로 위 단계를 반복한다.

---

ABSTRACT CORE (추상화된 핵심)

• 별도 MODULE의 하위 도메인 간에 상호작용이 활발한 경우 MODULE 간에 참조가 많이 만들어져서 분할의 가치가 줄어들거나, 간접적 상호작용으로 인해 모델이 불분명해질 수 있다.
• 따라서 모델의 가장 근본적인 개념을 식별해서 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출한다.
• 이 추상모델이 중요 컴포넌트 간의 상호작용을 대부분 표현할 수 있도록 설계해야 한다.
• 세부적인 클래스는 하위 도메인 MODULE에 남겨둔 채로 추상적이고 전체적인 모델을 자체적인 MODULE에 배치한다.
• 대부분의 특화된 클래스는 이제 다른 MODULE이 아닌 ABSTRACT CORE MODULE을 참조할 것이다.