DOMAIN VISION STATEMENT
문제
- 프로젝트 초기에는 모델이 존재조차 하지 않지만 모델의 개발에 집중해야 할 필요성은 거기에 있다.
- 개발이 후반부에 이르면 모델을 심층적으로 연구하지 않아도 되는 시스템의 가치를 설명할 필요가 생긴다.
- 도메인 모델의 핵심적인 측면이 다수의 BOUNDED CONTEXT에 걸쳐 있을지도 모르지만 정의상 이러한 개별 모델은 자신의 공통적인 초점을 보이게끔 구조화 될 수 없다.
해결
- CORE DOMAIN을 짧게 기술하고 그것이 가져올 가치에 해당하는 가치 제안을 작성하라.
- 이 도메인 모델과 다른 것과 구별하는 데 도움되지 않는 측면은 무시하라.
- 도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지 보여라.
- 한정된 범위에서 내용을 유지하라.
- 초기에 이선언문을 작성하고 새로운 통찰력을 얻을 때마다 선언문을 개정하라.
정리
- DOMAIN VISION STATEMENT는 팀 내에서 방향성을 공유하게 만들어준다. 그러므로 잘 활용해보자.
HIGHLIGHTED CORE
문제
- 팀의 의사소통 수준이 높지 않다면 VISION STATEMENT만으로는 거의 효과가 없다.
- 팀원들이 대체로 무엇이 CORE DOMAIN을 구성하는지 안다고 해도 사람들은 제각기 아주 유사한 구성요소를 고르지는 않을 테고 심지어 같은 사람이라도 이틀 연속으로 일관되게 선택하지 못한다.
- 끊임없이 모델을 걸러서 핵심적인 부분을 파악하는 정신적인 노동은 설계를 위한 사고에 유용한 집중력을 받아들이고 모델의 포괄적인 지식을 필요로 한다.
해결
- CORE DOMAIN과 CORE의 구성요소 사이에 일어나는 상호작용을 기술하는 매우 간결한 문서를 작성하라.
- 문서가 관리되지 않을 수도 있다.
- 문서를 아무도 읽지 않을지도 모른다.
- 문서 본연의 목적이 무의미해질 수도 있다.
- 최소주의를 지향한다.
정리
- 디스틸레이션 문서는 변경의 중요성을 나타내는 실질적인 지표로 작용한다.
COHESIVE MECHANISM
문제
- 개념적인 무엇 이 기계적인 어떻게 탓에 수렁이 빠진다.
- 문제 해결을 위한 알고리즘을 제공하는 수많은 메서드가 문제를 표현하는 메서드를 불분명하게 만든다.
해결
- 개념적으로 COHESIVE MECHANISM을 별도의 경량 프레임워크로 분할하라.
- 특히 형식주의나 잘 문서화된 알고리즘에 촉각을 곤두세워라.
- INTENTION-REVEALING INTERFACE로 프레임워크의 기능을 노출하라.
- 도메인의 다른 요소들은 해법의 복잡성(어떻게)을 프레임워크에 위임해서 문제(무엇)을 표현하는데 집중할 수 있다.
정리
- GENERIC SUBDOMAIN과 COHESIVE MECHANISM은 CORE DOMAIN의 역할을 덜어내는 맥락에서 비슷한점이 많다. 하지만 차이가 있다면 GENERIC SUBDOMAIN은 도메인이긴 하다는것이다 그만큼 중요한 반면 COHESIVE MECHANISM의 경우 도메인을 표현하진 않지만 모델에서 제기하는 일부 성가신 계산 문제를 해결해 준다. 이렇게 분리하게 되면 도메인을 이해하는데 많은 도움이 될것이다.
SEGREGATED CORE
문제
- 모델의 요소들은 부분적으로는 CORE DOMAIN의 역할을 수행하고 또 부분적으로는 보조 적인 역할을 수행한다.
- CORE의 개념적 응집성은 뚜렷이 나타나지 않거나 드러나지 않을지도 모른다.
- 모든 혼란과 얽힘은 CORE를 질식시킨다.
- 설계자가 가장 중요한 관계를 분명하게 볼 수 없다면 취약한 설계로 이어지는 결과가 나타난다.
해결
- 보조적인 역할로부터 CORE의 개념을 분리되게끔 모델을 리팩터링하고 CORE와 다른 코드와의 결합은 줄이면서 CORE의 응집력은 강화하라.
- 모든 일반적이거나 보조적인 역할을 하는 구성요소를 다른 객체로 추출해서 다른 패키지에 배치하라.
리팩토링 단계
- CORE 하위 도메인을 식별한다.
- 새로운 MODULE로 관련 클래스를 옮긴다.
- 개념을 직접적으로 표현하지 않는 서버 데이터와 기능으로 코드를 리팩터링한다.
- 새로 생긴 SEGREGATED CORE MODULE의 관계와 상호작용을 더욱 단순하고 전달력 있게 만들고 다른 MODULE과의 관계가 최소화되고 분명해지게끔 리팩터링한다.
- SEGREGATED CORE가 완전해질 때까지 또 다른 CORE 하위 도메인을 대상으로 위단계를 반복한다.
ABSTRACT CORE
문제
- 별도 MODULE의 하위 도메인 간에 상호작용이 활발한 경우 MODULE 간에 참조가 많이 만들어져야 해서 분할의 가치가 상당수 사라지거나, 또는 상호작용이 간접적으로 일어나야 해서 모델이 불분명해진다.
해결
- 모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라.
- 이 추상 모델이 중요 컴포넌트 간에 발생하는 상호작용을 대부분 표현할 수 있게끔 설계하라.
- 특화되고 세부적인 구현 클래스는 하위 도메인을 기준으로 정의된 자체적인 MODULE에 남겨둔 상태에서 이 추상적이면서 전체적인 모델을 자체적인 MODULE에 배치하라.
결론
- 디스틸레이션이라는 말은 DDD 공부하면서 처음 들어본 개념이였다. 하지만 소프트웨어 개발을 하면서 CORE DOMAIN을 더 잘 표현 하기 위해 이런 방법론들을 많이 시도해 보곤 했다. 다만 정확한 개념 없이 시도를 했던지라.. 부족한게 많다. 이번 디스틸레이션 방법론을 통해 CORE DOMAIN에 더 집중 할 수 있는 개발을 해나가야겠다.
기초를 탄탄하게