Recent changes

14 모델의 무결성 유지 [OPEN HOST SERVICE] 설명 보충 — ledyx 2024/11/07 08:00
Spring [Lifecycle Callbacks] — ledyx 2024/10/14 01:35
시작 [Bookmark] — ledyx 2024/09/10 04:30
2부 모델 주도 설계의 기본 요소 fix: 목차 링크 오류 수정 — ledyx 2024/08/29 16:52
17 전략의 종합 [종합 계획을 조심하라] — ledyx 2024/07/30 13:08

--- domain-driven_design:part_4_strategic_design:15_distillation [2024/07/22 13:33] – [SEGREGATED CORE] ledyx
+++ domain-driven_design:part_4_strategic_design:15_distillation [2024/07/29 11:27] (current) – [ABSTRACT CORE] 링크 오류 수정 ledyx
@@ Line 1: / Line 1: @@
 = 15 디스틸레이션 =
-폭넓은 일련의 모델을 구분하고 도메인 모델의 정수를 추출하는 방법
+폭넓은 일련의 모델을 구분하고 도메인 모델의 정수인 **CORE DOMAIN**을 추출하는 방법
 {{tag>Domain-Driven_Design  Modeling Design}}
@@ Line 380: / Line 380: @@
 === SEGREGATED CORE를 만드는 데 드는 비용 ===
+  * 특정 MODULE의 CORE DOMAIN의 응집도를 이끌어내기 위해 Cohesion이 희생될 수도 있는데, 엔터프라이즈 소프트웨어의 가장 큰 부가가치는 모델의 기업별 측면에서 나오기 때문에, 이를 CORE DOMAIN으로 이끌어내면 오히려 이득이다.
+  * CORE를 분리하려면 해야 할 일이 많기 때문에 개발자가 많은 시간을 보낸다.
+<note important>
+SEGREGATED CORE를 노출시켜야 할 때는
+규모가 큰 BOUNDED CONTEXT가 시스템에 결정적인 역할을 하지만
+많은 양의 보조적인 기능 탓에 **모델의 근본적인 부분이 가려지는 경우다.**
+</note>
 === 발전하는 팀의 의사결정 ===
+의사소통은 모든 사람이 CORE라는 하나의 시각을 함께 유지할 수 있을 만큼 효과적으로 이뤄져야 한다.
 ==  ABSTRACT CORE ==
+<note important>
+모델의 가장 근본적인 개념을 식별해서
+그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라.
+이 추상 모델이 중요 컴포넌트 간에 발생하는 **상호작용**을 대부분 표현할 수 있게끔 설계하라.
+특화되고 세부적인 구현 클래스는
+하위 도메인을 기준으로 정의된 자체적인 MODULE에 남겨둔 상태에서
+이 추상적이면서 전체적인 모델을 자체적인 MODULE에 배치하라.
+</note>
+ABSTRACT CORE를 모델링하려면
+핵심 개념과 해당 개념이 시스템의 주요 **상호작용**에서 수행하는 역할을 심층적으로 이해해야 한다.
+다시 말해, 이것은 [[domain-driven_design:part_3_refactoring_toward_deeper_insight:13_refactoring_toward_deeper_insight|더 심층적인 통찰력을 향한 리팩터링]]의 한 사례에 해당한다.
+그리고 __대개 여기에는 상당한 양의 재설계가 필요하다.__
 == 심층 모델의 디스틸레이션 ==
+<flow>
+flowchart
+subgraph subCoreDomain["CORE DOMAIN의 정제 → Project 전체"]
+  deepModel["Deep Model의 정제 → 한 도메인"]
+end
+</flow>
 == 리팩터링의대상 선택  ==
+CORE DOMAIN 분리에 집중.
+  - 고통 주도적(pain-driven) 리팩터링에서는 \\ 문제의 근원에 CORE DOMAIN이나, CORE와 지원 요소와의 관계가 관련돼 있는지 살핀다. \\ 만약 그렇다면, 이를 악물고 그 부분을 가장 먼저 고쳐야 한다.
+  - 마음껏 리팩터링할 수 있는 상황이라면 \\ 제일 먼저 CORE DOMAIN을 더 잘 분해하고, CORE의 격리를 개선하며, 보조적인 하위 도메인이 GENERIC하게 만드는 데 집중한다.

Line 1:

= 15 디스틸레이션 =

폭넓은 일련의 모델을 구분하고 도메인 모델의 정수를 추출하는 방법

폭넓은 일련의 모델을 구분하고 도메인 모델의 정수인 **CORE DOMAIN**을 추출하는 방법

Line 380:

=== SEGREGATED CORE를 만드는 데 드는 비용 ===

* 특정 MODULE의 CORE DOMAIN의 응집도를 이끌어내기 위해 Cohesion이 희생될 수도 있는데, 엔터프라이즈 소프트웨어의 가장 큰 부가가치는 모델의 기업별 측면에서 나오기 때문에, 이를 CORE DOMAIN으로 이끌어내면 오히려 이득이다.

* CORE를 분리하려면 해야 할 일이 많기 때문에 개발자가 많은 시간을 보낸다.

SEGREGATED CORE를 노출시켜야 할 때는

규모가 큰 BOUNDED CONTEXT가 시스템에 결정적인 역할을 하지만

많은 양의 보조적인 기능 탓에 **모델의 근본적인 부분이 가려지는 경우다.**

</note>

=== 발전하는 팀의 의사결정 ===

의사소통은 모든 사람이 CORE라는 하나의 시각을 함께 유지할 수 있을 만큼 효과적으로 이뤄져야 한다.

== ABSTRACT CORE ==

모델의 가장 근본적인 개념을 식별해서

그것을 별도의 클래스나 추상 클래스, 또는 인터페이스로 추출하라.

이 추상 모델이 중요 컴포넌트 간에 발생하는 **상호작용**을 대부분 표현할 수 있게끔 설계하라.

특화되고 세부적인 구현 클래스는

하위 도메인을 기준으로 정의된 자체적인 MODULE에 남겨둔 상태에서

이 추상적이면서 전체적인 모델을 자체적인 MODULE에 배치하라.

</note>

ABSTRACT CORE를 모델링하려면

핵심 개념과 해당 개념이 시스템의 주요 **상호작용**에서 수행하는 역할을 심층적으로 이해해야 한다.

다시 말해, 이것은 [[domain-driven_design:part_3_refactoring_toward_deeper_insight:13_refactoring_toward_deeper_insight|더 심층적인 통찰력을 향한 리팩터링]]의 한 사례에 해당한다.

그리고 __대개 여기에는 상당한 양의 재설계가 필요하다.__

== 심층 모델의 디스틸레이션 ==

<flow>

flowchart

subgraph subCoreDomain["CORE DOMAIN의 정제 → Project 전체"]

deepModel["Deep Model의 정제 → 한 도메인"]

end

</flow>

== 리팩터링의대상 선택 ==

CORE DOMAIN 분리에 집중.

- 고통 주도적(pain-driven) 리팩터링에서는 \\ 문제의 근원에 CORE DOMAIN이나, CORE와 지원 요소와의 관계가 관련돼 있는지 살핀다. \\ 만약 그렇다면, 이를 악물고 그 부분을 가장 먼저 고쳐야 한다.

- 마음껏 리팩터링할 수 있는 상황이라면 \\ 제일 먼저 CORE DOMAIN을 더 잘 분해하고, CORE의 격리를 개선하며, 보조적인 하위 도메인이 GENERIC하게 만드는 데 집중한다.

Sidebar

Recent changes

Menu

Differences

Sidebar

Recent changes

Menu