4부 전략적 설계

• 모델링 과정을 매우 복잡한 도메인까지 확장하는 원리
• 성공적인 모델 : 규모와는 상관없이 모순되거나 정의가 겹치지 않고 처음부터 끝까지 논리적인 일관성 유지
• Bounded Context 
• Distillation
• 대규모 구조 : 전혀 공통점이 없는 부분들이 맞물려 돌아가도록 일관성을 가져다 줌
• Responsibility Layer
• Evolving Order(발전하는 질서)

모델의 무결성 유지

• 각 모델이 적용되는 경계를 분명하게 합의하는 것에서 출발
• 단일화(unification) : 각 용어가 모호하지 않고 모순되는 규칙이 없는 모델의 내적 일관성
• 다른 여러 모델 간의 경계와 관계를 표시해줄 수단 필요
• Context Map : 프로젝트 분야를 매핑, 각 컨텍스트 간의 관계의 전체적인 개관
• Bounded Context : 각 모델의 적용가능성의 범위 정의
• Continuous Integration : 프로세스를 토대로 모델의 단일화 유지
• Shared Kernel
• Separate Ways

Bounded Context

• 규모가 큰 프로젝트에는 다수의 모델이 공존하며, 서로 다른 모델은 서로 다른 컨텍스트에 적용된다
• 한 팀 내에서도 다수의 모델이 공존할 수 있다
• 다수의 모델 탓에 발생하는 문제의 해결 방법
• 소프트웨어 내의 제한된 부분으로 특정 모델의 범위를 명확하게 정의
• 팀의 구성과 조화
• 컨텍스트의 경계를 팀 조직, 애플리케이션의 특정 부분에서의 사용법, 코드 기반이나 데이터베이스스키마와 같은 물리적인 형태의 관점에서 명시적으로 설정
• 경계 내에서는 모델을 엄격하게 일관된 상태로 유지하고 경계 바깥의 이슈 때문에 초점이 흐려지거나 혼란스러워져서는 안된다
• 모델을 책임지는 팀에서는 영속화를 비롯한 각 객체의 전체 생명주기를 다룬다

Bounded Context안의 균열 인식

• 코드로 작성된 인터페이스가 서로 맞지 않는 경우
• 예상치 못한 행위
• 언어를 혼동한 상태로 구사
• 중복개념 : 실제로 같은 개념을 나타내는 두개의 모델 요소가 존재하는 것
• 허위동족언어(false cognates) : 같은 용어를 사용하는 두 사람이 서로 같은 것을 이야기하고 있다고 생각하지만 실제로는 그렇지 않은 경우, 개념상의 충돌
• 해결방안
• Continuous Integration
• Context Map
• Shared Kernel
• Customer/Supplier Development Team
• Conformist
• Anticorruption Layer
• Separate Ways
• Open Host Service
• Published Language

Continuous Integration

• 내부적으로 균열이 발생할 때 이를 빠르게 포착하고 정정할 수 있을 정도로 컨텍스트 내의 모든 작업을 빈번하게 병합해서 일관성 유지
• 모델 개념의 통합
• 팀 구성원 간의 부단한 의사소통을 토대로 통합
• 구현 수준에서의 통합
• 모델내의 균열을 조기에 드러내는 체계적인 병합/빌드/테스트 프로세스를 토대로 통합
• 프로세스
• 단계적이고 재생 가능한 병합/빌드 기법    
• 자동화된 테스트 스위트
• 수정사항이 통합되지 않은 상태로 존재할 수 있는 시간을 적당히 짧게 유지하는 규칙

Context Map

• Bounded Context간에 코드를 재사용하는 것음 위험하므로 기능과 데이터는 번역 과정을 거쳐 통합해야 한다.
• 서로다른 컨텍스트간의 관계를 정의하고 프로젝트상의 모든 모델 컨텍스트를 아우르는 전체적인 뷰를 만들면 혼란을 줄일 수 있다
• Context Map은 프로젝트 관리와 소프트웨어 설계 영역 사이에 걸쳐있는 개념
• 의사소통을 위해 컨텍스트 간의 번역에 대한 윤곽을 명확하게 표현
• 컨텍스트 간에 공유해야 하는 정보를 강조
• 모델과 모델이 만나는 경계 지점 서술
• Bounded Context간의 관계 패턴
• Shared Kernel
• Customer/Supplier(현재 가장 많이 적용되어 있는 패턴)
• Separate Ways
• Open Host Service
• Anticorruption Layer(wrapper, translator, facade, service)

디스틸레이션

• 혼합된 요소를 분리해서 본질을 좀더 값지고 유용한 형태로 뽑아내는 과정
• Generic subdomain - 모델에서 가장 특색이 없는 측면 제거
• Coherent Mechanism - 용도가 다양하고, 의미전달이 용이하며, 유연한 설계를 통해 캡슐화
• Segregated Core
• Abstract Core - 가장 근본적인 개념과 관계를 순수한 형태로 표현
• Core Domain
• Domain Vision Statement - 최소한의 투자로 기본개념과 가치를 
• Highlighted Core - 의사소통을 향상시키고 의사결정에 도움

Core Domain

• 도메인 모델을 가치있는 자산으로 만들려면 모델의 핵심적인 측면을 다루기 수월해야 하고 애플리케이션의 기능성을 만들어내는 데 충분히 활용할 수 있어야 한다
• Core Domain은 시스템에서 가장 큰 가치가 더해지는 곳이다
• 시스템의 비전을 수행하기에 충분한 심층 모델을 찾고 유연한 설계를 개발할 수 있게 코어에 노력을 쏟아라

Generic Subdomain

• 모델은 일반 원칙(누구나 알고 있는것)이나 세부사항(보조적인 역할을 수행하는 전문 분야에 속하는 것) 탓에 정체된다
• 개발 시 선택사항
• 기성 솔루션(상용 또는 오픈소스)
• 공표된 설계나 모델
• 외주 제작
• 사내구현
• 일반화가 재사용 가능하다는 의미는 아니다
• 필요한 만큼만 투자
• 쉽기 때문에 보조 시스템을 먼저 구축할 경우 위험관리의 목적을 헛되게 할 수 있음

Domain vision Statement

• 도메인 모델의 본질과 해당 도메인 모델이 얼마나 기업에 가치 있는가에 초점을 맞춘다
• 팀 내에서 방향성을 공유하게 해 줌
• 작성방법
• Core Domain을 짧게 기술하고 그것이 가져올 가치에 해당하는 가치제안을 작성
• 이 도메인 모델과 다른것과 구별하는데 도움되지 않는 측면은 무시
• 도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지 보여라
• 한정된 범위에서 내용을 유지하라
• 초기에 이 선언문을 작성하고 새로운 통찰력을 얻을 때마다 선언문을 개정하라

Highlighted Core

• 어떤 모델에서 특별히 중요한 부분을 그것을 구체화한 구현과 함께 표시할 필요가 있는데, 이러한 표시는 모델에 대한 설명이지 반드시 모델 자체의 한 부분일 필요는 없다
• 기법
• 디스틸레이션 문서 : Core Domain과 Core의 구성요소 사이에서 일어나는 상호작용을 기술하는(3에서 7페이지 가량의) 매우 간결한 문서를 작성하라
• 표시된 Core : 모델의 주요 저장소 안에 있는 Core Domain의 구성요소에 대해 그것의 역할을 설명하려하지 말고 표시하라. 개발자가 힘들이지 않고도 Core의 안과 밖을 알 수 있게 하라

Cohesive Mechanism

• 의도를 드러내는 이름이 이정된 메서드에 복잡한 알고리즘을 숨기면 "무엇"이 "어떻게"와 분리된다
• 문제해결을 위한 알고리즘을 제공하는 수많은 메서드가 문제를 표현하는 메서드를 분분명하게 만드는 경우
• 개념적으로 Cohesive Mechanism을 별도의 경량 프레임워크로 분할
• Intention-Revealing Interface로 프레임워크의 기능을 노출
• 해법의 복잡성("어떻게")을 프레임워크에 위임해서 문제("무엇")을 표현하는데 집중    

Segregated Core

• 설계자가 가장 중요한 관계를 분명하게 볼 수 없다면 취약한 설계로 이어지는 결과가 나타난다
• 모든 일반적이거나 보조적인 역할을 하는 구성요소를 다른 객체로 추출해서 다른 패키지에 배치하라

Abstract Core

• 모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라
• 이 추상 모델이 중요 컴포넌트 간에 발생하는 상호작용을 대부분 표현할 수 있게끔 설계하라
• 특화되고 세부적인 구현클래스는 하위 도메인을 기준으로 정의된 자체적인 모듈에 남겨둔 상태에서 이 추상적이면서 전체적인 모델을 자체적인 모듈에 배치하라

리팩토링의 대상선택

• 문제의 근원에 Core Domain이나, Core 와 지원요소와의 관계가 있는지 살핀다. 그렇다면 가장먼저 고쳐야 한다
• 마음껏 리팩토링할 수 있는 상황이라면 제일먼저 Core Domain을 더 잘 분해하고 Core의 격리를 개선하며, 보조적인 하위 도메인이 Generic하게 만드는 데 집중한다.