This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| domain-driven_design:part_4_strategic_design:15_distillation [2024/07/22 12:00] – [선언적 형식의 디스틸레이션] ledyx | domain-driven_design:part_4_strategic_design:15_distillation [2024/07/29 11:27] (current) – [ABSTRACT CORE] 링크 오류 수정 ledyx | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| = 15 디스틸레이션 = | = 15 디스틸레이션 = | ||
| - | 폭넓은 일련의 모델을 구분하고 도메인 모델의 정수를 추출하는 방법 | + | 폭넓은 일련의 모델을 구분하고 도메인 모델의 정수인 **CORE DOMAIN**을 |
| {{tag> | {{tag> | ||
| Line 346: | Line 346: | ||
| 즉, 관련성 없는 세부사항 탓에 혼란을 겪지 않고도 **본질**에 직접적으로 도달하는 것이다. | 즉, 관련성 없는 세부사항 탓에 혼란을 겪지 않고도 **본질**에 직접적으로 도달하는 것이다. | ||
| </ | </ | ||
| + | |||
| + | [[part_3_refactoring_toward_deeper_insight: | ||
| == SEGREGATED CORE == | == SEGREGATED CORE == | ||
| + | |||
| + | CORE DOMAIN을 구조적으로 구별하는 데 직접적인 접근법 | ||
| + | |||
| + | GENERIC SUBDOMAIN을 추출하는 식으로 | ||
| + | 도메인에서 일부 CORE를 불분명하게 만드는 세부사항을 제거해 CORE를 눈에 띄게 만들 수 있지만 | ||
| + | 모든 하위 도메인을 식별하고 분명하게 하는 작업은 쉽지 않고, 이 중 일부는 그럴 만한 가치가 없는 듯 하다. | ||
| + | |||
| + | <note important> | ||
| + | 보조적인 역할(잘못 정의된 것을 비롯해)로부터 | ||
| + | CORE 개념을 분리되게끔 모델을 리팩터링하고 | ||
| + | CORE와 다른 코드와의 결합은 줄이면서 | ||
| + | CORE의 응집력은 강화하라. | ||
| + | 모든 일반적이거나 보조적인 역할을 하는 구성요소를 다른 객체로 추출해서 __다른 패키지에 배치__하라. | ||
| + | 심지어 이러한 과정이 매우 긴밀하게 결합돼 있는 요소를 분리하는 식으로 모델을 리팩터링하는 것을 의미하더라도 말이다. | ||
| + | </ | ||
| + | |||
| + | AOP와 비슷한 의미인듯. | ||
| + | |||
| + | |||
| + | SEGREGATED CORE로 리팩터링하는 단계는 대체로 아래와 같다. | ||
| + | |||
| + | - CORE 하위 도메인을 식별한다(디스틸레이션 문서에서 도출해야 할 수도 있음). | ||
| + | - 새로운 MODULE로 관련 클래스를 옮긴다. 이 때 MODULE의 이름은 관련 개념에 따라 짓는다. | ||
| + | - __개념을 직접적으로 표현하지 않는__ 서버 데이터와 기능으로 코드를 리팩터링한다. \\ 제거된 측면을 (아마도 새로 만들어진) __다른 패키지에 있는 클래스에 배치__한다. 그러한 측면은 개념상 관련 작업과 함께 둬야 하지만 완벽하게 하려고 __너무 많은 시간을 들여서는 안 된다.__ \\ CORE 하위 도메인의 불순물을 제거하고 그곳에서 다른 패키지를 참조하는 바를 명시적이 그 자체로도 이해할 수 있는 상태로 만드는 데 집중한다. | ||
| + | - 새로 생긴 SEGREGATED CORE MODULE의 관계와 __상호작용을 더욱 단순하고 전달력 있게 만들고__, | ||
| + | - SEGREGATED CORE가 완전해질 때까지 또 다른 CORE 하위 도메인을 대상으로 위 단계를 반복한다. | ||
| + | |||
| === SEGREGATED CORE를 만드는 데 드는 비용 === | === SEGREGATED CORE를 만드는 데 드는 비용 === | ||
| + | |||
| + | * 특정 MODULE의 CORE DOMAIN의 응집도를 이끌어내기 위해 Cohesion이 희생될 수도 있는데, 엔터프라이즈 소프트웨어의 가장 큰 부가가치는 모델의 기업별 측면에서 나오기 때문에, 이를 CORE DOMAIN으로 이끌어내면 오히려 이득이다. | ||
| + | * CORE를 분리하려면 해야 할 일이 많기 때문에 개발자가 많은 시간을 보낸다. | ||
| + | |||
| + | <note important> | ||
| + | SEGREGATED CORE를 노출시켜야 할 때는 | ||
| + | 규모가 큰 BOUNDED CONTEXT가 시스템에 결정적인 역할을 하지만 | ||
| + | 많은 양의 보조적인 기능 탓에 **모델의 근본적인 부분이 가려지는 경우다.** | ||
| + | </ | ||
| + | |||
| === 발전하는 팀의 의사결정 === | === 발전하는 팀의 의사결정 === | ||
| + | |||
| + | 의사소통은 모든 사람이 CORE라는 하나의 시각을 함께 유지할 수 있을 만큼 효과적으로 이뤄져야 한다. | ||
| + | |||
| == ABSTRACT CORE == | == ABSTRACT CORE == | ||
| + | |||
| + | <note important> | ||
| + | 모델의 가장 근본적인 개념을 식별해서 | ||
| + | 그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라. | ||
| + | 이 추상 모델이 중요 컴포넌트 간에 발생하는 **상호작용**을 대부분 표현할 수 있게끔 설계하라. | ||
| + | 특화되고 세부적인 구현 클래스는 | ||
| + | 하위 도메인을 기준으로 정의된 자체적인 MODULE에 남겨둔 상태에서 | ||
| + | 이 추상적이면서 전체적인 모델을 자체적인 MODULE에 배치하라. | ||
| + | </ | ||
| + | |||
| + | |||
| + | ABSTRACT CORE를 모델링하려면 | ||
| + | 핵심 개념과 해당 개념이 시스템의 주요 **상호작용**에서 수행하는 역할을 심층적으로 이해해야 한다. | ||
| + | 다시 말해, 이것은 [[domain-driven_design: | ||
| + | 그리고 __대개 여기에는 상당한 양의 재설계가 필요하다.__ | ||
| + | |||
| == 심층 모델의 디스틸레이션 == | == 심층 모델의 디스틸레이션 == | ||
| + | |||
| + | < | ||
| + | flowchart | ||
| + | |||
| + | subgraph subCoreDomain[" | ||
| + | deepModel[" | ||
| + | end | ||
| + | |||
| + | </ | ||
| + | |||
| == 리팩터링의대상 선택 | == 리팩터링의대상 선택 | ||
| + | CORE DOMAIN 분리에 집중. | ||
| + | |||
| + | - 고통 주도적(pain-driven) 리팩터링에서는 \\ 문제의 근원에 CORE DOMAIN이나, | ||
| + | - 마음껏 리팩터링할 수 있는 상황이라면 \\ 제일 먼저 CORE DOMAIN을 더 잘 분해하고, | ||