Sidebar

Recent changes

Menu

Trace: • Linux • 3부 더 심층적인 통찰력을 향한 리팩터링 • Git • Domain-Driven Design • Spring
Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
domain-driven_design [2024/02/17 15:38] – ↷ Links adapted because of a move operation ledyxdomain-driven_design [2024/02/17 15:59] (current) – 4부 분리 ledyx
Line 12: Line 12:
  
 {{tag>Domain-Driven_Design  Modeling Design}} {{tag>Domain-Driven_Design  Modeling Design}}
 +
  
 == 서문 == == 서문 ==
  
-{{::ddd_mm_00.png|}}+[[domain-driven_design:part_0_orientation|서문]]
  
-== 1부 동작하는 도메인 모델 만들기 ==+ 
 +== 1부 동작하는 도메인 모델 만들기  ==
  
 Part I: Putting the Domain Model to Work Part I: Putting the Domain Model to Work
  
-=== 서론 === +[[domain-driven_design:part_1_putting_the_domain_model_to_work|1부 동작하는 도메인 모델 만들기]]
- +
-==== 용어 정의 ==== +
- +
- +
-===== 도메인 ===== +
- +
-대개 컴퓨터와 관련 없다 +
- +
-  * 사용자가 프로그램을 사용하는 대상 영역 +
-    * 사용자의 활동 +
-    * 사용자의 관심사 +
- +
- +
-===== 모델 ===== +
- +
-도메인 지식의 부담을 해소하기 위한 도구 +
- +
-  * 대상을 **단순화** 한 것 +
-    * 어떤 사실을 해석한 것 +
-    * 당면의 문제를 해결하는 것과 관련된 측면으로 추상화 +
-      * 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다! +
-  * 도메인 지식을 **선택적으로 단순화**하고 **의식적으로 구조화**한 형태 +
-  * 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 **팀의 합의된 방식** <sup>01 동작하는 도메인 만들기, 4p</sup> +
-  * 프로젝트에 참여한 사람들의 **머릿속에 축적된 개념을 모아 놓은 것**으로서 도메인에 대한 통찰력을 반영하는 **용어**와 **관계**로 표현된다. <sup>02 의사소통과 언어 사용, 23p</sup> +
-    * 관계(relationships) : 모든 언어에 내재된 **결합 규칙** <sup>02 의사소통과 언어 사용, 26p</sup> +
- +
-===== 도메인 모델 ===== +
- +
-  * 특정한 다이어그램이 아니라\\ **다이어그램이 전달하고자 하는 아이디어** +
-  * 도메인 지식을 **엄격하게 구성**하고 **선택적으로 추상화**한 것 +
-  * 일련의 개념들을 모아놓은 것 <sup>77p</sup> +
- +
- +
- +
-==== 도메인 주도 설계에서의 모델의 유용성 ==== +
- +
-DDD에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다 +
- +
-  * 모델과 핵심 설계는 **서로 영향을 주며 구체화**된다 (3장 참고) +
-    * 모델을 의미 있게 만들고 \\ 모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장하는 것은 \\ **모델과 구현 간의 긴밀한 연결**  +
-    * 모델을 이해한 바에 근거해 코드를 해석할 수 있기 때문 +
-  - 모델은 모든 팀 구성원이 사용하는 **언어의 중추** +
-    * 모델과 구현이 서로 연결 → 개발자와 도메인 전문가간의 **번역**이 필요하지 않음 +
-  - 모델은 **지식의 정수**만을 뽑아낸 것이다 +
-    * 모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 → 공유 언어 사용!! +
- +
- +
-==== 소프트웨어의 본질 ==== +
- +
-해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력. 그 뿐만 아니라 모델링 기법을 연마해서 도메인 설계에 통달해야 한다. +
- +
-    대부분의 유능한 개발자는 다뤄야 할 특정 도메인을 학습하는 데 관심이 많지 않으며, +
-    더군다나 도메인 모델링 기법을 쌓는 데는 더더욱 전념하지 않는다. +
-    엔지니어들은 자신의 기술력을 훈련할 수 있는 정략적인 문제를 좋아한다. +
- +
-=== Chapter === +
- +
-  * [[domain-driven_design:part_1_putting_the_domain_model_to_work:01_crunching_knowledge|01 지식 탐구]] +
-  * [[domain-driven_design:part_1_putting_the_domain_model_to_work:02_communication_and_the_use_of_language|02 의사소통과 언어 사용]] +
-  * [[domain-driven design:Part I Putting the Domain Model to Work:03 Binding Model and Implementation|03 모델과 구현의 연계]]+
  
  
Line 88: Line 30:
 Part II: The Building Blocks of a Model-Driven Design Part II: The Building Blocks of a Model-Driven Design
  
-<note> +[[domain-driven_design:part_2_the_building_blocks_of_a_model-driven_design|2부 모델 주도 설계의 기본 요소]]
-구현을 모델과의 밀접한 관계로 유지하기 위한 ** 모델링과 설계의 우수 실천 법**을 적용해야 한다. +
-... +
- +
-도메인 주도 설계 과정을 탄력성 있게 만들려면 개발자들은 **잘 알려진 근본 원리들**이 **어떻게 Model-Driven Design**을 뒷받침하는지 이해해야 한다. +
-... +
- +
-3개의 장은 **패턴 언어로**로 구성돼 있으며, 미묘한 모델의 특징과 설계 의사결정이 어떻게 도메인 주도 설계 과정에 영향을 주는지 보여주겠다 +
-... +
- +
-정교한 모델은 **가장 근본적인 사항에 관심을 가질 때만** 비로소 복잡성을 헤쳐나갈 수 있으며, 이는 팀에서 확신을 갖고 결합할 수 있는 상세 요소라는 결과로 나타난다. +
-</note> +
- +
- +
-=== Chapter === +
- +
-  * [[domain-driven design:Part II The Building Blocks of a Model-Driven Design:04 Isolating the Domain|04 도메인의 격리]] +
-  * [[domain-driven design:Part II The Building Blocks of a Model-Driven Design:05 A Model Expressed in Software|05 소프트웨어에서 표현되는 모델]] +
-  * [[domain-driven design:Part II The Building Blocks of a Model-Driven Design:06 The Life Cycle of a Domain Object|06 도메인 객체의 생명 주기]] +
-  * [[domain-driven design:Part II The Building Blocks of a Model-Driven Design:07 Using the Language An Extended Example|07 언어의 사용: 확장 예제]]+
  
  
Line 114: Line 37:
 Part III: Refactoring Toward Deeper Insight Part III: Refactoring Toward Deeper Insight
  
-  * 유용한 모델을 성공적으로 개발하기 위해 명심해야 할 세 가지 관건 +[[domain-driven_design:part_3_refactoring_toward_deeper_insight|3부 더 심층적인 통찰력을 향한 리팩터링]]
-    * 정교한 도메인 모델은 만들 수 있으며, 노력을 들일 만한 가치가 있다. +
-    * 해당 도메인을 학습하는 개발자와 도메인의 전문가의 **긴밀한 참여**와 **반복적인 리팩터링** 과정 없이 유용한 모델을 개발하기란 쉽지 않다. +
-    * 유용한 모델을 효과적으로 구현하고 사용하려면 **정교한 설계 기술**이 필요할지도 모른다. +
- +
- +
-=== 리팩터링 수준 === +
- +
-Levels of Refactoring +
- +
-<note important> +
-시스템의 생존력에 가장 큰 영향을 미치는 리팩터링은 +
-(기술적인 관점보다) +
-**도메인에 대한 새로운 통찰력을 얻었을때 수행**하거나 +
-코드를 사용해서 **모델이 표현하고자 하는 바를 명확하게 드러내고자 수행**하는 경우다. +
-(= 심층 모델을 향한 리팩터링) +
- +
-리팩터링의 목표는 개발자가 단순히 코드가 수행하는 바를 이해하는 것뿐만 아니라 +
-**왜 그렇게 수행되는지를 이해하고 도메인 전문가와의 의사소통에 이를 연관**시키는 것이다. +
-</note> +
- +
- +
-=== 심층 모델 === +
- +
-Deep Models +
- +
-도메인의 **피상적[(본질적인 현상은 추구하지 아니하고 겉으로 드러나 보이는 현상에만 관계하는 것)]인 측면은 배제**하고 +
-도메인 전문가의 **주요 관심사**와 **가장 적절한 지식**을 알기 쉽게 표현하는 모델이다. +
-**이 정의가 __추상화를 의미하는 것은 아니다__**. +
-심층 모델이 일반적으로 추상적인 요소를 포함하기는 하지만 +
-**문제의 핵심을 관통하는 구체적인 요소** 또한 포함할 수 있다. +
- +
-도메인과 조화를 이루는 모델에서는 융통성, 단순함, 설명력을 얻을 수 있다. +
-그러한 모델이 공통적으로 지니고 있는 한 가지 특징은 **__업무 전문가__가 즐겨 쓰는 단순하지만 충분히 추상적인 언어**가 존재한다는 것이다. +
- +
- +
-=== 심층 모델/유연한 설계 === +
- +
-Deep Model/Supple Design +
- +
-[[https://wiki.ledyx.xyz/domain-driven_design/10_supple_design|10 유연한 설계]] +
- +
-Supple Design은 변경을 촉진할 뿐 아니라 **모델 자체의 개선**에도 기여한다. +
-Model-Driven Design을 지탱하는 두 개의 축이 있다. +
-심층 모델은 **<sup>①</sup>설계의 표현력을 부여**한다. +
-그와 동시에 개발자가 여러 가지 시도를 할 수 있을 정도로 설계가 유연하고 +
-개발자가 무슨 일이 일어나고 있는지 파악할 수 있을 만큼 설계가 명확하다면 +
-**<sup>②</sup>모델의 발견 과정에 통찰력을 제공**할 수 있다. +
- +
- +
-=== 발견 과정 === +
- +
-The Discovery Process +
- +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:09 Making Implicit Concepts Explicit|09 암시적인 개념을 명확하게 만들기]] : 도메인의 중심 개념을 찾아 설계에 반영하는 방법을 다룬다 +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:10 Supple Design|10 유연한 설계]] : 쉽게 확장하고 변경할 수 있는 소프트웨어를 작성하는 방법을 다룬다 +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:11 Applying Analysis Patterns|11 분석 패턴의 적용]], [[domain-driven design:12 Relating Design Patterns to the Model|12 모델에서 디자인 패턴 연결]] : 모델링 삽질을 줄일 수 있는 방법 소개. 이러한 패턴은 바로 사용 가능한 해결책은 아니지만 __면밀한 지식 검토 과정에 도움을 주고 조사해야 할 범위를 줄여준다.__ +
- +
- +
-=== Chapter === +
- +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:08 Breakthrough|08 도약]] +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:09 Making Implicit Concepts Explicit|09 암시적인 개념을 명확하게 만들기]] +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:10 Supple Design|10 유연한 설계]] +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:11 Applying Analysis Patterns|11 분석 패턴의 적용]] +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:12 Relating Design Patterns to the Model|12 모델에서 디자인 패턴 연결]] +
-  * [[domain-driven design:Part III Refactoring Toward Deeper Insight:13 Refactoring Toward Deeper Insight|13 더 심층적인 통찰력을 향한 리팩터링]] +
  
 == 4부 전략적 설계 == == 4부 전략적 설계 ==
Line 187: Line 43:
 Part IV: Strategic Design Part IV: Strategic Design
  
-=== Chapter === +[[domain-driven_design:part_4_strategic_design|4부 전략적 설계]]
- +
-  * [[domain-driven design:Part IV Strategic Design:14 Maintaining Model Integrity|14 모델의 무결성 유지]] +
-  * [[domain-driven design:Part IV Strategic Design:15 Distillation|15 디스틸레이션]] +
-  * [[domain-driven design:Part IV Strategic Design:16 Large-Scale Structure|16 대규모 구조]] +
-  * [[domain-driven design:Part IV Strategic Design:17 Bringing the Strategy Together|17 전략의 종합]] +
domain-driven_design.1708184322.txt.gz · Last modified: 2024/02/17 15:38 by ledyx