15장_디스틸레이션

• (Distillation 사전적 의미 : 증류, 증류물, 정수)
• 디스틸레이션 : 혼합된 요소를 분리해서 본질을 좀 더 값지고 유용한 형태로 뽑아내는 과정
  모델은 지식의 정수를 추출한 것 - p427
• 화학적인 증류과정을 거치는 것과 마찬가지로 Sub Domain과 Coherent Mechanism(응집력 있는 매커니즘) 로 분리
  이러한 노력은 Core Domain (SW를 차별화하고 구축할 가치가 있게 만들어 주는 부분) 을 추출하는데 목적
  그림 15-1 전략적 디스틸레이션에 대한 Navigation Map - p429

 

 

 

Core Domain(핵심 도메인)

• 이해하기 힘든 시스템은 변경하기도 어렵다.
  위험한 요소는 도메인에 대한 큰 그림을 잃게 됨으로써 야기된다.
  설계 측면의 우선순위를 매겨야함
  도메인 모델을 가치 있는 자산으로 만들려면 모델의 핵심적인 측면을 다루기 수월해야 함 - p430
• Core Domain : Application의 목적에 특유(부합)하고 중심적인 모델
  모델을 요약하라.
  Core Domain을 찾아 그것을 지원하는 다수의 모델과 코드로 부터 쉽게 구별할 수 있는 수단을 제공하라.
  Core를 작게 만들어라
  Core Domain에 가장 재능있는 인력을 할당하고 그에 따라 인력을 채용하라 - p432
• 디스틸레이션을 시작하려면 모델에서 가장 특색이 없는 측면을 제거해도 된다 - p435

 

 

 

Generic SubDomain (일반 하위 도메인)

• 프로젝트를 위한 것이 아닌(목표인 Core Domain에서 벗어나는 영역) 응집력 있는 하위 도메인을 식별
  Core Domain보다 낮은 우선순위를 부여, 이일에는 핵심 개발자를 배치하지 않는다
  Sub Domain에 대해서는 기성솔루션이나 공표된 모델을 고려해본다 - p436

p437

Sub Domain에 적용가능한 방법	유리한 점	불리한 점
선택1) 기성 솔루션 - 구현된 제품을 구입 또는 오픈소스 이용	- 개발할 코드가 적어진다 - 유지보수 부담이 외부화 - 코드가 좀 더 성숙하고 다양한 곳에서 사용되므로 개발된 코드에 비해 실수가 적다	- 사용하기전에 평가하고 이해하는 시간 필요 - 품질관리가 업계에서 이뤄지므로 올바르고 안정적일 거라 확신할 수 없음 - 용도에 비해 과도하게 만들어져 있을지도 모름, 사내 구현에 비해 통합에 드는 노력이 더 클수도 있음 - 외부 요소는 대개 매끄럽게 통합되지 않음, 외부 요소는 별도의 BC - 플랫폼 의존성, 컴파일러 버전 의존성 등을 야기할 수 있음
선택2) 공표된 설계나 모델	- 사내모델보다 더 성숙하고 많은 사람들의 통찰력을 반영 - 즉각적이고 높은 품질의 문서화	- 요구사항에 딱 맞지 않거나 과도한 설계일 수 있음
선택3) 외주 제작된 구현 - 자동화된 테스트는 외주 제작에 중요 - 구현자는 단위 테스트 제공 - 품질 보증, 명세화, 통합을 위한 자동화된 인수테스트 필요	- 대부분의 지식이 필요하고 축적되는 Core Domain과 관련된 업무에서 핵심팀을 해방 - Core Domain의 지식이 흩어져 없어지지 않고 더욱 많은 개발 가능 - 명세가 외부로 전달돼야 하므로 인터페이스 중심의 설계가 이뤄지고 하위 도메인을 일반화된 상태로 유지하는데 도움	- 인터페이스, 코딩 표준 등 의사소통이 필요하므로 여전히 핵심팀에서 시간을 들여 구현을 살펴봐야함 - 코드를 이해해야하기 때문에 소유권을 내부로 이전하는데 상당한 부담 - 코드 품질이 고르지 않음
선택4) 사내구현	- 통합 유리 - 정확히 원하는 것만 얻음 - 임시 계약자를 할당할 수 있음	- 계속되는 유지보수와 교육 부담 - 패키지 개발에 필요한 시간과 비용을 과소평가하기 쉬움

• 일반화가 재사용 가능하다는 의미는 아니다 - p443
  - (Sub Domain)을 사내 개발하든 외주 제작하든 해당 코드의 재사용에 신경 써서는 안 된다
  - Core Domain에 가능한 많은 노력을 기울이고 보조적인 성격의 Sub Domain에는 필요한 만큼만 투자해야 함
• 프로젝트의 위험 관리 - p444
  애자일 프로세스에서는 가장 위험스러운 업무를 먼저 다루는 식으로 위험을 관리
  XP에서는 종단간(end to end)시스템을 구축하고 그것을 즉시 작동하게 만들도록 요구
  이러한 초기 시스템은 종종 기술적인 아키텍처를 검증하는 역할
  어떤 프로젝트는 기술적 위험이 크고, 어떤 프로젝트는 도메인 모델링과 관련한 위험이 더 크다

 

 

 

Domain Visioni Statement (도메인 비전 선언문)

• 약 한페이지 분량으로 Core Domain을 짧게 기술하고, 그것이 가져올 가치에 대한 '가치 제안'을 작성하라
  도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지
  초기에 선언문을 작성하고 (지속적으로) 개정 - p446
  p447 선언문 예
  도메인 비전 선언문은 팀 내에서 방향성을 공유하게 만들어준다

 

 

 

Highlighted Core (강조된 핵심)

• 디스틸레이션 문서는 완전한 설계문서가 아니다, 최소 진입점으로서 Core의 윤곽을 드러내고 설명,
  폭 넓게 바라볼수 있게...
  그러므로 Highlighted Core의 한 형태로
  Core Domain과 Core의 구성요소 사이에서 일어나는 상호작용을 기술하는 간결한 문서를 작성하라

 

 

 

 

Cohesive Mechanism (응집력 있는 매커니즘)

• 매커니즘을 캡슐화하는 것은 객체지향 설계의 표준 원칙
  의도를 드러내는 이름이 지정된 매서드에 복잡한 알고리즘을 숨기면 '무엇'이 '어떻게'와 분리된다 - p453
• 책임과 분리가 일어나고 Core Domain이나 Sub Domain의 모델이 사실이나 규칙, 또는 문제를 정형화하게 된다.
  그리고 Cohesive Mechanism은 모델에 구체화돼 있는 대로 규칙을 결정하거나 계산을 완효한다. - p454
• Sub Domain와 Cohesive Mechanism - p455
  - 둘다 Core Domain의 부담을 더는 데 목적
  - Sub Domain : 덜 중심적이고, 덜 중요하하고, 덜 특화됐다는 점을 제외하면 Core Domain과 크게 다르지 않음
  - Cohesive Mechanism : 도메인을 나타내지 않음, 모델에서 제기하는 일부 성가신 계산 문제를 해결해줄 뿐,
    모델이 제안하면 Cohesive Mechanism은 처리한다

 

 

Segregated Core (분리된 핵심)

• Segregated Core를 노출시켜야할 때는 규모가 큰 BC가 시스템에 결정적인 역할을 하지만 
  많은 양의 보조적인 기능 탓에 모델의 본질적인 부분이 가려지는 경우 - p460
  화물 해운 모델의 Core 분리 - p461
• Segregated Core로 Refactoring하는 단계(참고) - p459
  1) Core의 하위 도메인을 식별
  2) 새로운 Module로 관련 클래스를 옮김, 이 때 Module의 이름은 관련 개념에 따라 명명
  3) 개념을 직접적으로 표현하지 않는 서버 데이터와 기능으로 코드를 Refacotring
  4) 새로 생긴 Segregated Core Module의 관계와 상호작용을 단순화, 다른 Module과의 관계 최소화
  5) Segregated Core가 완전해질 때까지 또 다른 하위 도메인을 대상으로 위의 단계를 반복

 

 

Abstract Core (추상화된 핵심)

• 모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라.
  이 추상 모델이 중요 컴포넌트 간에 발생하는 상호작용을 대부분 표현할 수 있게끔 설계하라 - p468
• Refactoring의 대상 선택
  형편없이 나눠져 있는 큰 규모의 시스템에 직면한다면 어디서부터 시작할 것인가?
  전부 Refactoring할수도 없고, Pain Driven일수도 없다면 어떻게 해야할까?
  - Pain Driven(고통 주도적) Refactoring에서는 문제의 근원에 Core Domain이나,
    Core와 지원 요소와의 관계가 관련돼 있는지 살핀다. 만약 그렇다면, 이를 악물고 그 부분을 가장 먼저 고쳐야한다.
  - 마음껏 Refactoring할 수 있는 상황이라면 제일 먼저 Core Domain을 더 잘 분해하고, 
    Core의 격리를 개선하며, 보조적인 하위 모데인이 Generic하게 만드는데 집중한다.