도메인 주도 설계 4부 독서 후기 Part.2 (feat. DDD)

안녕하세요. yeTi입니다.
오늘은 도메인 주도 설계 4부를 읽고 난 느낌을 기록하려고 합니다.

지난 편에 이어 오늘은 4부(전략적 설계)의 2편입니다.

15장 디스틸레이션 - CORE DOMAIN (핵심 도메인)

지금까지 맥락을 살펴보면 지식을 얻고 쌓아나가며 언어의 맥락을 일치해 같은 개념을 가지는 것을 중심에 두고 에릭 에반스는 이야기를 풀어나가고 있습니다.

이를 달성하기 위한 중심 패러다임은 MODEL-DRIVEN DESIGN 을 채용하고 있고 경험의 누적에 따른 통찰력이 모델로 표현되어야 한다고 말합니다.

모델이 설계를 더 잘 지원하기 위해 정제되는 것처럼 설계 또한 새로운 통찰력을 도메인에 반영하기 위해 정제돼야 한다. - p.172, 7장 언어의 사용 - 도메인 격리

해당 장에서는 지식을 어떻게 정제하여 추출할 것인지를 보다 전략적으로 설명하려는 것으로 보입니다.

모델은 지식의 정수를 추출한 것이다. - p.427

모델이 지식을 적절하게 담아내지 못한다면 어떻게 될까요?

이해하기 힘든 시스템은 변경하기도 어렵다. 아울러 변경의 효과도 예측하기 어렵다. <중략> 기존 팀원조차도 코드가 그다지 표현력 있지 않거나 정리가 잘 돼 있지 않으면 파악하느라 고생할 것이다.) <중략> 어떤 행위가 다른 곳에 이미 존재한다는 사실을 개발자가 알지 못하면 중복이 일어나고 시스템이 훨씬 더 복잡해진다. - p.430

모델이 지식을 적절하게 담아내지 못한다면 시스템을 이해하기 힘들어지고 변경하기 어려워집니다. 게다가 기존 동작을 파악하는 시간을 낭비할 수 있고 중복이 난무할 수 있습니다.

그렇다면 어떻게 해야할까요?

도메인 모델을 가치 있는 자산으로 만들려면 모델의 핵심적인 측면을 다루기 수월해야 하고 애플리케이션의 기능성을 만들어내는 데 충분히 활용할 수 있어야 한다. - p.430,431

에릭 에반스는 핵심적인 측면을 다루기 쉽도록 만들어야 한다고 합니다. 이 핵심적인 측면을 표현한 것이 CORE DOMAIN 입니다.

다시 한번 그 동안의 맥락을 짚어보면 지식을 쌓아 모델-설계-구현에 표현할 수 있도록 엔티티나 모듈, 서비스와 같은 개념을 제시했고 생명주기를 관리하기 위해 팩토리와 레포지토리라는 개념을 제시했습니다.

그리고 통찰력을 적용하기 위해 리펙토링이나 설계 패턴을 보며 제약 사항을 관리하기 위해 명세라는 개념을 제시하기도 했습니다.

이 모든 활동은 도메인 모델을 표현하기 위한 방법들이라는 생각이 드는데, CORE DOMAIN 은 어떻게 다른지 궁금증이 듭니다.

가령, 엔티티나 도메인 서비스가 구성되어 있을 것인데 CORE DOMAIN 은 또 어떻게 관리되는지 궁금해집니다.

어떤 CORE DOMAIN을 선택하느냐는 본인의 관점에 달렸다. <중략> 도메인에 대한 통찰력이 경험에 의해 깊어지면 일반화된 화폐 개념이 분리되고 오로지 모델의 특화된 측면만 CORE DOMAIN에 유지되어 디스틸레이션 프로세스가 계속될 수 있다. - p.432-433

어찌됐든 CORE DOMAIN을 선택하는 것은 주관적인 활동인데 지속적인 경험에 의해 통찰력을 가지는 과정이 디스틸레이션(distillation), 증류하는 과정입니다.

---

여기까지 읽으면서 현업에서 CORE DOMAIN 을 변경하는 것이 좋겠다는 생각이 들었습니다.

지금까지는 견적의 관점이 핵심 도메인으로 다가왔었는데 순간적으로 견적을 중심으로 협업하는 활동이 핵심 도메인이라는 생각이 들었습니다.

이러한 생각의 발현들이 디스틸레이션(distillation)의 과정이라는 생각이 듭니다.

---

그렇다면 누가 CORE DOMAIN 을 식별할까요?

어떻게 해서든 고유한 소프트웨어를 개발하는 일은 결국 전문지식을 축적하고 지식을 면밀히 검토해서 풍성한 모델을 만들어내는 안정화된 팀에서 해야 할 일이다. 지름길은 없다. 마법의 탄환도 없다. - p.435

결국 팀에서 해결하는 것이 중요하다고 에릭 에반스는 말합니다. 왜냐하면 통찰력이란 지식을 축적하고 검토하는 것에서 출발하기 때문입니다.

간혹 팀의 역량이 부족하다고 판단하여 외부 설계 전문가를 고용하는 경우가 있는데, 이러한 행동이 대개 도움이 되지 않는다고 에릭 에반스는 말합니다. 저도 지금까지 경험내에서도 에릭 에반스의 말에 동의합니다.

왜냐하면 통찰력은 어디에서 오는가? 라는 것을 봤을 때 단기적인 지식과 업무에서 오는 것이 아니라 지속적인 고민과 시도에서 온다고 믿기 때문에 외부 전문가가 심층 모델을 달성하기에는 욕망이나 시간이라는 측면에서 부족하다고 생각합니다.

마법의 탄환은 없습니다.

GENERIC SUBDOMAIN(일반 하위 도메인)

디스틸레이션을 단계적으로 확대한다는 의미는 지속적으로 증류하여 CORE DOMAIN 을 명확하게 만들도록 노력하는 것입니다.

그 노력의 중심에는 안정된 팀이 있어야 하기 때문에 GENERIC SUBDOMAIN(일반 하위 도메인)을 식별하여 팀의 역량이 분산되는 것을 막고 확보한 역량을 CORE DOMAIN 을 심화하는데 사용해야 합니다.

그러한 일반적인 모델 요소가 매우 중요한 것으로 여겨지더라도 전체 도메인 모델은 시스템에서 가장 가치를 더하는 특별한 측면을 두드러지게 하고, 가능한 한 그 부분에 많은 힘이 실리게끔 구조화해야 한다. CORE가 모든 상호 관련된 요소와 섞여 있다면 이렇게 하기 어렵다. - p.436

GENERIC SUBDOMAIN의 가치는 핵심 도메인을 보다 명확하게 식별하도록 하고 비교적 덜 중요한 하위 도메인, 그것도 일반적으로 통용할 수 있는 개념의 것을 다른 방식으로 개발을 하여 팀의 부담을 줄이는 것입니다.

GENERIC SUBDOMAIN의 특성 자체가 보편적으로 많이 사용하는 개념을 맥락으로 묶은 것이기 때문에 배경 지식을 위한 노력이 적으므로 판단이나 적응을 빠르게 할 수 있습니다.

---

GENERIC SUBDOMAIN 이 식별되고 나면 다양한 방식으로 팀의 부담을 줄일 수 있습니다.

1. 기성 솔루션
2. 공표된 설계나 모델
3. 외주제작된 구현
4. 사내 구현

GENERIC SUBDOMAIN 을 읽으면서 팀의 역량을 어떻게 집중해야하는지 깨닫게 되는것 같습니다.

개발자의 욕심으로는 모든것을 직접 만들어나가고 싶지만 비즈니스와 시장이라는 현실에서 시간이 그것들을 기다려주지 않는 경우가 있습니다.

그리고 그 동안의 경험내에서 팀의 외부에서 만들어진 것들이 팀으로 전달이되면 그 또한 팀의 부담을 가중시키는 경험을 했기 때문에 회의적인 시각도 있었습니다.

그러나 GENERIC SUBDOMAIN 을 명확하게 식별한다면 해당 범위내에서 팀의 외부 역량을 적절하게 이용할 수 있다는 생각이 들었고 이후에 팀 내부로 전달이 됐을 때도 부담이 크지 않을 것 같다는 생각이 들었습니다.

---

두 시간대에 관한 이야기를 보며 필요하다고 느껴서 바로 만들기 보다는 CORE DOMAIN 을 구체화하는 과정에서 GENERIC SUBDOMAIN 의 타당성을 먼저 실험하고 GENERIC SUBDOMAIN 이 명확하게 식별되었을 때 앞서 제시한 예시중 하나를 선택하여 목적을 달성하는 과정이 합리적이고 매끄럽게 느껴졌습니다.

도메인의 경계를 식별하는 과정에는 실험이 필요하다는 생각이 듭니다.

그리고 이어서 재사용성을 언급합니다. 최근에 재사용성이라는 개념으로 고민을 한 시간이 있어서 눈에 확 띄는 단어였습니다.

코드 재사용에 대해서는 언급하지 않았다. 기성 솔루션이 하나의 특정한 상황에는 맞거나 맞지 않을 수도 있지만 사내에서 개발하든 외주 제작하든 스스로 코드를 구현한다고 가정하면 특히 해당 코드의 재사용에 신경 써서는 안 된다. 이는 디스틸레이션의 기본적인 동기에 어긋난다. 즉, 여러분은 CORE DOMAIN에 가능한 한 많은 노력을 기울이고 보조적인 성격의 GENERIC SUBDOMAIN에는 필요한 만큼만 투자해야 한다는 것이다. - p.443

순간 GENERIC SUBDOMAIN 이 흔히 표현하는 공통 서비스라는 생각이 들었습니다. 생각해볼 수록 GENERIC SUBDOMAIN 을 서비스적으로 표현한 단어라는 생각이 듭니다.

그렇다면 공통 서비스라는 표현으로 식별한 GENERIC SUBDOMAIN 은 일반화와 재사용성이라는 측면으로 접근하기 쉽습니다.

왜냐하면 이미 개념부터 GENERIC SUBDOMAIN 이기 때문입니다.

따라서 에릭 에반스의 염려가 더욱 의미있게 와닿았습니다. 우리는 CORE DOMAIN에 가능한 한 많은 노력을 기울이고 보조적인 성격의 GENERIC SUBDOMAIN에는 필요한 만큼만 투자해야 합니다.

---

프로젝트의 위험 관리는 CORE DOMAIN 을 중심으로 이뤄져야 하는데 그 이유는 가장 어려우면서 중요하기 때문입니다.

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

DOMAIN VISION STATEMENT

DOMAIN VISION STATEMENT 는 흡사 프로젝트의 개요나 스타트업에서 가지는 비전이나 핵심가치를 표현한 간략한 페이지와 동일하게 보입니다.

(약 한 페이지 분량으로) CORE DOMAIN을 짧게 기술하고 그것이 가져올 가치에 해당하는 "가치 제안"을 작성하라. 이 도메인 모델과 다른 것과 구별하는 데 도움되지 않는 측면은 무시하라. 도메인 모델이 어떻게 다양한 관심사를 충족하고 균형을 이루는지 보여라. 한정된 범위에서 내용을 유지하라. 초기에 이 선언문을 작성하고 새로운 통찰력을 얻을 때마다 선언문을 개정하라. - p.446

확실히 우리가 만들어갈 중심 모델이나 핵심 가치를 명확하게 표현하고 지속적으로 공유를 한다면 서비스의 feature 를 식별하거나 우선순위를 정의함에 있어 명확한 기준을 가질 수 있겠다는 생각이 들었습니다.

개발팀 입장에서도 모델을 식별하고 구체화함에 있어 중요하다고 생각하는 CORE DOMAIN 이 서비스의 가치와 같은 맥락을 가질 수 있기 때문에 비즈니스의 변화에 보다 적절하게 대응할 수 있을 것이라고 기대를 합니다.

그러나 현실에서 보면 스스로가 무엇을 핵심 가치로 할 것인지조차 모르는 경우를 볼 수 있습니다.

이것은 애자일의 태동으로도 연결되는것 같습니다. 고객조차 스스로 무엇을 원하는지 모르기 때문에 빠르게 만들어보며 욕망을 식별해나가는 과정이 필요합니다.

어찌 되었든 욕망을 식별해나가는 과정에서 핵심 가치를 가지지 않으면 결국 투자자들에게 명확한 설명이 불가능하므로 핵심 가치를 식별하고 정리하여 관련자들과 공유하는 것은 팀이 같은 생각을 하고 유연하게 문제를 해결해나가는데 도움이 될 것이라고 생각합니다.

이어지는 생각으로 안영회 대표님의 로드맵에 대한 오해를 줄이기 위한 설명에서 언급하는 로드맵도 DOMAIN VISION STATEMENT 와 비슷한 맥락이라는 생각이 듭니다.

로드맵은 전략 문서이기 때문에 일련의 기능이나 솔루션이 아니라 초점을 맞춰 해결해야 하는 고객 문제에 관한 테마다. 로드맵을 테마로 전환하는 것은 엄청나게 강렬하다. - 고객 문제에 집중하여 우선순위를 선정하기

HIGHLIGHTED CORE

문서화는 필요합니다.

팀원들이 대체로 무엇이 CORE DOMAIN을 구성하는지 안다고 해도 사람들은 제각기 아주 유사한 구성요소를 고르지는 않을 테고 심지어 같은 사람이라도 이틀 연속으로 일관되게 선택하지는 못할 것이다. <중략> 코드에 현저한 구조적 변경을 가하는 것이 CORE DOMAIN을 식별하는 이상적인 방법이겠지만 그러한 구조적 변경이 단기간에도 언제나 실용적인 것은 아니다. 사실 그러한 중요하고 구조적인 코드 변경은 팀에게 없는 바로 그 시각이 없다면 수행하기가 쉽지 않다. - p.446

2024-02-23
이제서야 HIGHLIGHTED CORE 가 무엇을 하고자 의도한 것인지 깨닫게 되었습니다. 우리가 CORE DOMAIN을 식별했다고 가정하더라도 CORE DOMAIN을 구성하는 구성요소들을 일관되게 선택하기 힘들기 때문에 이를 문서에 표시해 두자는 것입니다.

에릭 에반스는 개인간 다른 개념을 가지고 있는 이유와 개인의 일관적인 판단의 어려움을 전제하고 있습니다. 그리고 생각의 표현을 코드로 하면 좋겠지만 현실에서는 시간이라는 제약에서 어려움으로 다가올 수 있다고 말합니다.

충분히 공감이 되는 상황입니다.

그렇다면 이를 어떻게 풀어나가야 할까요?

디스틸레이션 문서는 완전한 설계 문서가 아니다. 그것은 최소주의적인 진입점으로서 CORE의 윤곽을 드러내고 설명하며, 특정 부분을 좀더 면밀하게 조사하는 이유를 제기한다. 디스틸레이션 문서를 읽는 사람은 각 조각이 어떻게 맞아떨어지는가를 폭넓게 바라볼 수 있게 되며 더욱 상세한 세부사항을 살펴보려면 어떤 코드를 참고해야 하는지 안내한다. - p.449

2024-02-23
디스틸레이션 문서의 목적니아 효용가치를 보다 이해할 수 있는 시간이 되었습니다. 어떤 코드를 참고해야 하는지 안내하는 가이드 문서로 활용할 수 있다는 것입니다.
실무 상황에 응용해보면 패키지 구조를 문서화하고 우리가 인지하는 도메인들이 개념화되어 있는지 확인해 볼 수 있습니다.

앞서 언급한 문서화를 해야합니다. 완전한 설계문서가 아닌 최소주의에 입각한 문서를 만들어 CORE DOMAIN 을 이해하는 시야를 넓힐 수 있도록 해야합니다.

왜 최소주의적인 입장을 가져야 할까요?

문서를 별도로 유지했을 때 발생하는 통상적인 위험 요소는 다음과 같다.

1. 문서가 관리되지 않을 수도 있다.
2. 문서를 아무도 읽지 않을지도 모른다.
3. 정보의 출처가 늘어남으로써 복잡성을 관통하는 문서 본연의 목적이 무의미해질 수도 있다.

오랜 기간 문서의 낭비를 바라보는 시각을 가진 저로써는 매우 공감이 되는 요소들입니다.

그럼에도 불구하고 서로 간의 생각의 틀을 맞추기 위해서는 코드와 언어외의 매개체가 필요합니다.

그렇다면 어떻게 표현할까요? 설명으로 표현할까요?

모델의 주요 저장소 안에 있는 CORE DOMAIN의 구성요소에 대해 그것의 역할을 설명하려 하지 말고 표시하라. 개발자가 힘들이지 않고도 CORE의 안과 밖을 알 수 있게 하라. - p.451

이미 가지고 있는 문서들이 존재한다면 중요한 구성요소들을 표시하고 간략한 설명을 덧붙여 핵심을 인식할 수 있도록 하는 것이 중요합니다.

게다가 잘만 활용하면 CONTINUOUS INTEGRATION 의 수단으로 사용할 수도 있습니다.

디스틸레이션 문서가 CORE DOMAIN의 본질적인 면면의 윤곽을 드러낸다면 디스틸레이션 문서는 모델 변경의 중요성을 나타내는 실질적인 지표로 작용한다. 모델이나 코드 변경이 디스틸레이션 문서에 영향을 주면 다른 팀원과의 상의가 필요하다. 변경이 일어나면 모든 팀원에게 이러한 사실을 즉시 알리고 새로운 버전의 문서를 배포해야 한다. CORE의 밖이나 디스틸레이션 문서에 포함되지 않은 세부사항에 가해진 변경은 상의나 통보없이 통합될 수 있으며, 이러한 변경사항은 다른 팀원의 업무를 진행하는 과정에서 마주치게 될 것이다. 이때 개발자는 XP가 제안하는 완전한 자치를 누리게 된다. - p.452

디스틸레이션 문서를 모델 변경의 트리거로 활용한다면 지식이나 통찰이 집약되고 공유될 수 있을 것이라고 에릭 에반스는 말합니다.

DOMAIN VISION STATEMENT 와 HIGHLIGHTED CORE 는 실무에 적용해보고 효과를 느껴보고 싶은 욕망이 들게 합니다.

COHESIVE MECHANISM

코드로 표현하다보면 어떻게라는 방식에 매몰되어 무엇을 하는지 불분명해지는 경우가 있습니다. 이는 객체지향에서 말하는 메시징에 집중하라와 생각이 연결됩니다.

때때로 계산은 설계를 부풀리기 시작하는 수준의 복잡성에 이르기도 한다. 개념적인 "무엇이" 기계적인 "어떻게" 탓에 수렁에 빠진다. 문제 해결을 위한 알고리즘을 제공하는 수많은 메서드가 문제를 표현하는 메서드를 불분명하게 만드는 것이다. - p.453

이는 나중에 코드를 보게되었을 때 어떻게 계산하는지는 읽히지만 왜 그렇게 하는지를 몰라 이후 수정이 어려운 경우가 발생합니다.

에릭 에반스는 어떻게를 표현하기 위해 COHESIVE MECHANISM 을 사용하라고 말합니다.

그러고 나면 이러한 분리된 메커니즘은 보조적인 역할에 머물게 되고, 더욱 선언적인 형식의 인터페이스를 통해 메커니즘을 사용하는, 더 작고 더 표현력 있는 CORE DOMAIN을 남긴다. - p.453

COHESIVE MECHANISM 은 보다 명확하게 CORE DOMAIN 을 표현하기 위한 방법이 됩니다.

이러한 맥락에서 GENERIC SUBDOMAIN 과 비슷해 보이지만 모델과 구현이라는 관점에서 차이를 가지고 있습니다.

이런 점에서 GENERIC SUBDOMAIN은 단지 덜 중심적이고, 덜 중요하며, 덜 특화됐다는 점을 제외하면 CORE DOMAIN과 전혀 다르지 않다. 반면 COHESIVE MECHANISM은 도메인을 나타내지 않는다. COHESIVE MECHANISM은 표현력 있는 모델에서 제기하는 일부 성가신 계산 문제를 해결해줄 뿐이다. - p.455

GENERIC SUBDOMAIN 은 CORE DOMAIN 과 같이 도메인을 바라보는 시각을 표현하지만 COHESIVE MECHANISM 은 모델의 표현력을 떨어뜨리는 계산을 응집하기 때문입니다.

여기서 에릭 에반스는 재미있는 실무내 현상을 언급합니다.

하지만 그렇게 하는 것은 훗날 또 하나의 설계상의 점진적인 향상에 해당할 것이다. 그리고 그러한 다음 단계로 나아갈지 여부는 다음과 같은 비용편익 분석을 기반으로 결정될 것이다. 즉, 새로운 설계를 고안해내는 것은 얼마나 어려울 것인가? 현행 설계를 이해하고 수정하는 것은 얼마나 어려운가? 좀더 발전된 설계가 해당 업무를 하게 될 사람들에게 얼마나 더 쉬울 것인가? 그리고 당연한 얘기지만 새로운 모델이 어떤 형태를 취할지 알고 있는 사람이 있는가? - p.456

CORE DOMAIN 에서 MECHANISM 을 발견했을 때 비용편익 분석을 한다는 것입니다.

흔하게 이상적으로 보이니까 바꾸자라는 생각을 가질 수 있지만 이를 실천했을 때 가질 수 있는 이득을 고려해봐야 한다는 것입니다.

• 좀더 발전된 설계가 해당 업무를 하게 될 사람들에게 얼마나 더 쉬울까요?
• 새로운 모델이 어떤 형태를 취할지 알고 있는 사람이 있을까요?

그리고 MECHANISM 의 회귀 현상에 대해서도 언급합니다.

이러한 회귀 현상은 흔히 나타나지만, 그렇다고 처음으로 되돌아가는 것은 아니다. 이러한 회귀 현상의 최종 결과는 대개 사실과 목표, MECHANISM을 좀더 명확하게 구분짓는 더 심층적인 모델이다. 실용적인 리팩터링은 불필요한 복잡성은 버리면서 중간 단계상의 중요 이점은 계속 유지한다. - p.457

간혹 갈피를 못 잡는다라는 부정적인 인식이 있는 현상이지만 맥락만 이어진다면 심층적인 모델로의 발전으로 볼 수 있다는 것을 느낍니다.

리팩터링의 대상 선택

켄트 벡의 생각을 쫒고 있는 저로써는 동의할 수 없는 내용을 XP 커뮤니티라는 단체를 대상으로 표현하여 흥미가 생겼습니다.

형편없이 나눠져 있는 큰 규모의 시스템에 직면한다면 어디서부터 시작할 것인가? XP 커뮤니티에서는 이 질문에 다음과 같은 대답이 나오곤 한다.

1. 모든 부분을 리팩터링해야 할 테니 그냥 아무데서나 시작한다.
2. 어디든 골치아픈 곳에서 시작한다. 나라면 나한테 떨어진 특정 업무를 해결하는 데 필요한 부분을 리팩터링하겠다. - p.469

이전에 공유한 켄트 벡의 트윗에서 켄트 벡은 다음과 같이 말했습니다.

Software design is preparation for change.

소프트웨어의 설계는 변화를 준비하기 위한 것이라고 켄트 벡은 말합니다.

그러한 맥락에서 리팩터링을 바라본다면 리팩터링의 대상은 변화의 가능성이 가장 많은 곳입니다.

반면, 에릭 에반스는 리팩터링의 대상을 CORE DOMAIN 을 중심으로 다루라고 말합니다.

1. 고통 주도적 리팩터링에서는 문제의 근원에 CORE DOMAIN이나, CORE와 지원 요소와의 관계가 관련돼 있는지 살핀다. 만약 그렇다면, 이를 악물고 그 부분을 가장 먼저 고쳐야 한다.
2. 마음껏 리팩터링할 수 있는 상황이라면 제일 먼저 CORE DOMAIN을 더 잘 분해하고, CORE의 격리를 개선하며, 보조적인 하위 도메인이 GENERIC하게 만드는 데 집중한다.
   이것이 바로 리팩터링에 들인 노력으로부터 최고의 가치를 얻는 방법이다. - p.470

개인적으로 저는 켄트 벡의 지향점이 실용적이고 명확하다고 생각합니다.

왜냐하면 변화하기 원한다는 것이 현재 우리가 비즈니스를 만들어감에 있어 가장 필요한 부분일 가능성이 높을 것이기 때문입니다.

반면, CORE DOMAIN의 관점에서 본다면 CORE DOMAIN 식별하고 변화에 대응하는 것보다 변화를 대응하는 과정에서 생긴 통찰력으로 CORE DOMAIN 을 식별하는 것이 좀더 쉽게 다가오기도 합니다.

SEGREGATED CORE(분리된 핵심)

SEGREGATED CORE(분리된 핵심) 를 읽으면서 앞서 에릭 에반스가 언급했던 CORE DOMAIN(핵심 도메인)이나 GENERIC SUBDOMAIN(일반 하위 도메인) 을 분리하는 것과 무슨 차이가 있는지 감이 오질 않았습니다.

왜냐하면 CORE DOMAIN 이나 GENERIC SUBDOMAIN 을 식별하는 행위내에 SEGREGATED 라는 의미가 포함되어있기 때문입니다.

SEGREGATED CORE로 가기로 했다면 잠재적으로 전 시스템에 걸쳐 변경하느라 개발자가 많은 시간을 보내리라는 점을 인정해야 한다. SEGREGATED CORE를 노출시켜야 할 때는 규모가 큰 BOUNDED CONTEXT가 시스템에 결정적인 역할을 하지만 많은 양의 보조적인 기능 탓에 모델의 본질적인 부분이 가려지는 경우다. - p.460

그러나 생각의 전환으로 다수의 CORE DOMAIN 이나 GENERIC SUBDOMAIN 을 만드는 것을 시도하는 것을 의미하는 방향으로 변경해봤지만 뭔가 찜찜한 기분이 남아있었습니다.

반복해서 읽다가 뭔가 감이 오는 문단을 찾았습니다. SEGREGATED CORE 가 관점에 의존성을 가지고 있는 듯한 말입니다.

여기서는 화물 취급, 즉 고객 요구에 따른 화물 인도에 집중해야 한다. 이러한 활동과 가장 직접적으로 관련된 클래스를 추출함으로써 그림 15.3과 같은 Delivery (배송)라는 새로운 패키지에 SEGREGATED CORE가 만들어진다. - p.462

지금까지 이어진 생각으로는 BOUNDED CONTEXT 가 가지는 CORE DOMAIN 이 있지만 크기가 커져서 우리가 해결하고자 하는 방향을 뚜렷하게 표현하지 못할 때 SEGREGATED CORE 를 통해서 하위 도메인을 추출하는 전략으로 보입니다.

이러한 시각을 가지고 첫 문단을 다시 읽어보니 맥락이 맞는 듯한 느낌을 받습니다.

CORE의 개념적 응집성은 뚜렷이 나타나지 않거나 드러나지 않을지도 모른다. 이러한 모든 혼란과 얽힘은 CORE를 질식시킨다. 설계자가 가장 중요한 관계를 분명하게 볼 수 없다면 취약한 설계로 이어지는 결과가 나타난다. - p.458

우리가 핵심이라고 생각해서 CORE DOMAIN 으로 정의를 했지만 지속적인 개발 활동에서 개념적 응집성이 약해지는 경우가 있습니다. 이럴 때, SEGREGATED CORE 로 하위 도메인을 만들어 개념적 응집성을 높일 수 있습니다.

그리고 GENERIC SUBDOMAIN 과의 차이점은 자체적인 응집력을 가졌느냐입니다.

마무리

디스틸레이션(distillation) 에서 말하고자 하는 바는 단어의 뜻인 증류 그대로 입니다.

물이든 석유든 특정 물질은 다양한 혼합물로 구성되어 있는데, 증류라는 활동을 통해서 고유한 원소를 추출할 수 있습니다.

이번 15장은 디스틸레이션(distillation) 이라는 개념을 설계라는 활동에 비유하여 설명한 장입니다.

개발이라는 활동을 하면서 다양한 개념을 다룹니다.

때로는 다양한 것을 다루다가 방향성을 잃고 비즈니스적으로 중요한 요소보다 덜 중요한 요소에 집중하여 힘을 빼는 경우를 볼 수 있습니다.

에릭 에반스는 이러한 비효율을 방지하고자 CORE DOMAIN (핵심 도메인) 을 식별하자고 말합니다. 그러기 위해서는 자연스럽게 GENERIC SUBDOMAIN(일반 하위 도메인) 을 식별하여 역량이 분산되는 것을 방지해야 하고, DOMAIN VISION STATEMENT 나 HIGHLIGHTED CORE 를 활용하여 간결한 문서로 우리가 집중해야 할 것들을 기록하는 것도 좋다고 말합니다.

또 한, COHESIVE MECHANISM 을 활용하여 도메인적 요소가 아닌 로직적인 부분은 별도로 관리하는 것이 좋다고 말하며, CORE DOMAIN (핵심 도메인) 이 커져 효용성이 떨어졌을 때는 SEGREGATED CORE(분리된 핵심) 을 활용하여 다시 CORE DOMAIN (핵심 도메인) 을 식별하라고 합니다.

디스틸레이션(distillation) 이라는 활동이 코딩을 하는 개발자들을 위한 개념에 국한 된 것이 아니라 지식 노동자들이라면 해야하는 활동이라는 생각이 듭니다.

지난 기록

• 도메인 주도 설계 4부 독서 후기 Part.1 (feat. DDD)
• 도메인 주도 설계 3부 독서 후기 Part.2 (feat. DDD)
• 도메인 주도 설계 3부 독서 후기 Part.1 (feat. DDD)
• 도메인 주도 설계 2부 독서 후기 (feat. DDD)
• 도메인 주도 설계 1부 독서 후기 (feat. DDD)
• 15장 디스틸레이션 - SEGREGATED CORE(분리된 핵심)
• 15장 디스틸레이션 - 리팩터링의 대상 선택
• 15장 디스틸레이션 - COHESIVE MECHANISM
• 15장 디스틸레이션 - HIGHLIGHTED CORE
• 15장 디스틸레이션 - DOMAIN VISION STATEMENT
• 15장 디스틸레이션 - GENERIC SUBDOMAIN(일반 하위 도메인)
• 15장 디스틸레이션 - CORE DOMAIN (핵심 도메인)