GENERIC SUBDOMAIN(일반 하위 도메인)

[jongfeel]

GENERIC SUBDOMAIN(일반 하위 도메인)

현재 진행중인 프로젝트를 위한 것이 아닌 응집력 있는 하위 도메인을 식별하라.
이러한 하위 도메인에서 일반화된 모델 요소를 추출해서 별도 MODULE에 배치하라.
해당 MODULE에는 전문성위 자취를 남기지 않는다.

하위 도메인이 분리되고 나면 CORE DOMAIN보다 낮은 우선순위를 부여하고 핵심 개발자를 배치하지 않는다.
그리고 이런 GENERIC SUBDOMAIN에 대해서는 기성솔루션 혹은 공표된 모델을 고려해본다.

---

이런 패키지 개발에 몇 가지 선택 사항이 있다.

• 기성 솔루션
• 공표된 설계나 모델
• 외주제작된 구현
• 사내 구현

선택1: 기성 솔루션

제품 구입 혹은 오픈소스 이용

유리한점

• 개발 코드가 적어진다.
• 유지보수 부담이 외부화된다.
• 코드가 좀더 성숙하고 다양한 곳에서 사용되므로 사내에서 개발된 코드에 비해 실수가 적고 완전하다.

불리한점

• 사용하기 전에 평가하고 이해하는 시간이 필요하다.
• 품질관리가 업계에서 이뤄지므로 올바르고 안정적이라 확신할 수 없다.
• 용도에 비해 과도하게 만들어져 있을 가능성. 통합에 드는 농력이 더 클 수 있다.
• 외부 요소는 대체로 통합이 어렵다. 별도의 BOUNDED CONTEXT 혹은 다른 패키지의 ENTITY를 자연스럽게 참조하기가 쉽지 않을 수 있다.
• 플랫폼 의존성, 컴파일러 버전 의존성 문제

기성 솔루션은 조사할만한 가치는 있지만 크게 노력을 들일 만한 가치는 없다.
하위 컴포넌트가 일반적일수록 모델은 좀더 정수를 추출한 상태가 되고 유용하게 쓰일 기회가 더 많다고 볼 수 있다.

선택2: 공표된 설계나 모델

유리한 점

• 사내 모델보다 더 성숙되고 많은 사람들의 통찰력을 반영한다.
• 즉각적이고 높은 품질의 문서화

불리한 점

• 요구사항에 딱 맞지 않거나 과도한 설계일 수 있다.

분야가 정형화되어 있고 엄밀한 모델이 있을 때는 그걸 사용한다.
회계와 물리 분야이다.
자주 사용되고 문서화가 잘 되어 있거나 정형화된 모델을 활용할 수 있을 때는 시간과 노력을 낭비할 이유가 없다.

선택 3: 외주제작된 구현

유리한 점

• CORE DOMAIN과 관련된 업무에서 핵심 팀을 해방시켜 준다.
• 팀을 영구히 확대하거나 CORE DOMAIN의 지식이 흩어져 없어지지 않고 더 많은 개발이 이뤄질 수 있다.
• 명세가 외부로 전달돼야 하므로 인터페이스 중심의 설계가 이뤄지고 하위 도메인을 일반화된 상태로 유지하는 데 도움이 된다.

불리한 점

• 인터페이스, 코딩 표준, 의사소통이 필요하므로 핵심 팀에서 시간을 들여 구현을 살펴봐야 한다.
• 코드를 이해해야 하기 때문에 소유권을 내부로 이전하는 데 상당한 부담이 된다.
• 코드 품질이 고르지 않다. 팀간 상대적 역량에 따라 좋거나 나쁘거나 할 수 있다.

자동화된 테스트가 외주 제작에 중요한 역할을 할 수 있다.

선택 4: 사내 구현

유리한 점

• 통합하기 쉬움
• 정확히 원하는 것만을 얻음
• 임시 계약자를 할당할 수 있음

불리한 점

• 계속되는 유지보수와 교육 부담
• 패키지 개발에 필요한 시간과 비용을 과소평가하기 쉬움

---

GENERIC SUBDOMAIN은 외부 설계 전문가를 적용해 볼 수 있는 분야다.
GENERIC SUBDOMAIN에서는 특화된 CORE DOMAIN을 심층적으로 이해하지 않아도 되고
해당 도메인을 배울 기회도 좀처럼 없기 때문이다.

시간이 흐르면
CORE 모델의 구성은 한정적이 되고
더 많은 일반화된 모델이 프레임워크나 공표된 모델, 분석 패턴의 형태로 이용할 수 있게 될 것이다.
그것들을 CORE DOMAIN 모델과 나누는 데는 상당한 가치가 있다.

예제: 두 시간대에 관한 이야기

첫 번째
화물 해운에 필요한 스케줄링 소프트웨어의 설계에서
국제 운송 일정을 조정하려면 정확한 시간 계산이 필요하고
모든 일정이 지역시간으로 추적되기 때문에 시간을 변환하지 않고 운송을 조정하기란 불가능하다.

애플리케이션이 성숙해지기 시작하면서 기존 시간 클래스는 쓰기 적합하지 않았고
요구사항이 명확해져서 기성 솔루션을 찾지 못한 상태에서 직접 구축할 수 밖에 없었다.

해운 업무와 관련된 지식을 연마할 필요가 없었으므로
프로젝트에 임시 계약직으로 투입된 프로그래머를 배정했다.

두 번째
보험 회사에서 새로운 보상처리 시스템을 개발 하는 중
다양한 사건이 발생한 시각을 지역시간으로 기록하는 일이었다.

시간대 코드는 단순히 지역시간을 시간대로 표시해서 저장하기만 하면 됐으므로
변환 코드를 따로 만들 필요는 없었지만
두 프로그래머가 배치됐고 애플리케이션에서 직접 사용하지도 않은 상태였다.

문제는 시간대에 집중하느라 발생한 비용이 CORE DOMAIN 모델의 소홀함으로 이어진 것이다.
CORE DOMAIN에 에너지를 쏟았다면 애플리케이션을 실제 가동시키고 도메인 모델의 최초 산출물을 만들어냈을 것이다.

두 프로젝트에서 얘기할 부분은
GENERIC 시간대 모델을 CORE DOMAIN과 분리했다는 점이다.
해운이나 보험의 시간대 모델은 CORE를 이해하기 어렵게 만들 수 있다.

기술자들은 시간대 변환과 같은 범위가 한정돈 문제를 즐기는 경향이 있고
그런 문제에 시간을 보내는 것을 쉽게 정당화한다.
그러나 우선순위를 바라보는 안목을 연마하면 보통 CORE DOMAIN을 염두에 두게 된다.

일반화가 재사용 가능하다는 의미는 아니다.

코드의 재사용에 대해 신경 써서는 안 된다.
이는 디스틸레이션의 기본적인 동기에 어긋난다.
CORE DOMAIN에 가능한 많은 노력을 기울이고
보조적인 성격의 GENERIC SUBDOMAIN에서는 필요한 만큼만 투자해야 한다.

재사용이 일어나도 항상 코드 재사용에 해당되는 건 아니다.
나중에 관련 프로젝트에서 가치가 있을 수는 있지만
처음부터 완벽한 일반성을 갖춘 모델을 개발할 필요는 없다.
당면 업무에 필요한 부분에 대해서만 모델링 하고 구현해도 된다.

재사용을 목표로 설계할 일은 없더라도
일반 개념의 범위 내에서 설계를 유지하는 것과 관련해서는 엄격해야 한다.

프로젝트 위험 관리

애자일에서는 가장 위험한 업무를 먼저 다루는 식으로 위험 관리를 한다.
XP는 end-to-end 시스템을 구축하고 그걸 즉시 작동하게 만들도록 요구한다.
이런 초기 시스템은 기술적인 아키텍처를 검증하는 역할을 한다.

그리고 일부 분석하기 쉬운 GENERIC SUBDOMAIN을 다루는 보조 시스템을 구축하려고 하는데
위험관리의 목적을 헛되게 할 수 있으므로 주의해야 한다.

프로젝트는 양쪽에서 오는 위험에 직면하는데
어떤 프로젝트는 기술적 위험이 더 크고
어떤 프로젝트는 도메인 모델링과 관련된 위험이 더 크다.

그래서 최초로 만들어진 시스템은 CORE DOMAIN의 특정 부분에 기반을 둬야 하고 그럼에도 단순해야 한다.

위험도가 높은 업무를 추진하려는 모든 프로세스에도 같은 원칙이 적용된다.
CORE DOMAIN은 매우 위험도가 높은데
CORE DOMAIN이 예상외로 쉽지 않고
CORE DOMAIN 없이는 프로젝트가 성공할 수 없기 때문이다.