This is an old revision of the document!


Domain-Driven Design

Tackling Complexity in the Heart of Software

복잡한 도메인(문제 영역)을 이해하고 모델링하고, 공통 언어로 소통하는데 초점을 맞추는 방법론.

  • DDD는 모델을 동작하게 만들어 애플리케이션의 문제를 해결한다.p.62
    • 지식 탐구 → Ubiquitous Language 사용 → (단일) 모델 생성 → 모델과 구현을 밀접하게 연관 시킴
  • DDD의 목표는 기술보다는 도메인에 대한 모델에 집중해 더 나은 소프트웨어를 만들어내는 것이다.p.154

본문 내용 출처 : Eric Evans. 『도메인 주도 설계』. 이대엽(역). 위키북스, 2011.

서문

1부 동작하는 도메인 모델 만들기

Part I: Putting the Domain Model to Work

서론

용어 정의

도메인

대개 컴퓨터와 관련 없다

  • 사용자가 프로그램을 사용하는 대상 영역
    • 사용자의 활동
    • 사용자의 관심사
모델

도메인 지식의 부담을 해소하기 위한 도구

  • 대상을 단순화 한 것
    • 어떤 사실을 해석한 것
    • 당면의 문제를 해결하는 것과 관련된 측면으로 추상화
      • 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다!
  • 도메인 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
  • 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 01 동작하는 도메인 만들기, 4p
  • 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서 도메인에 대한 통찰력을 반영하는 용어관계로 표현된다. 02 의사소통과 언어 사용, 23p
    • 관계(relationships) : 모든 언어에 내재된 결합 규칙 02 의사소통과 언어 사용, 26p
도메인 모델
  • 특정한 다이어그램이 아니라
    다이어그램이 전달하고자 하는 아이디어
  • 도메인 지식을 엄격하게 구성하고 선택적으로 추상화한 것
  • 일련의 개념들을 모아놓은 것 77p

도메인 주도 설계에서의 모델의 유용성

DDD에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다

  • 모델과 핵심 설계는 서로 영향을 주며 구체화된다 (3장 참고)
    • 모델을 의미 있게 만들고
      모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장하는 것은
      모델과 구현 간의 긴밀한 연결
    • 모델을 이해한 바에 근거해 코드를 해석할 수 있기 때문
  1. 모델은 모든 팀 구성원이 사용하는 언어의 중추
    • 모델과 구현이 서로 연결 → 개발자와 도메인 전문가간의 번역이 필요하지 않음
  2. 모델은 지식의 정수만을 뽑아낸 것이다
    • 모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 → 공유 언어 사용!!

소프트웨어의 본질

해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력. 그 뿐만 아니라 모델링 기법을 연마해서 도메인 설계에 통달해야 한다.

  대부분의 유능한 개발자는 다뤄야 할 특정 도메인을 학습하는 데 관심이 많지 않으며,
  더군다나 도메인 모델링 기법을 쌓는 데는 더더욱 전념하지 않는다.
  엔지니어들은 자신의 기술력을 훈련할 수 있는 정략적인 문제를 좋아한다.

Chapter

2부 모델 주도 설계의 기본 요소

Part II: The Building Blocks of a Model-Driven Design

구현을 모델과의 밀접한 관계로 유지하기 위한 모델링과 설계의 우수 실천 법을 적용해야 한다.

도메인 주도 설계 과정을 탄력성 있게 만들려면 개발자들은 잘 알려진 근본 원리들어떻게 Model-Driven Design을 뒷받침하는지 이해해야 한다.

3개의 장은 패턴 언어로로 구성돼 있으며, 미묘한 모델의 특징과 설계 의사결정이 어떻게 도메인 주도 설계 과정에 영향을 주는지 보여주겠다

정교한 모델은 가장 근본적인 사항에 관심을 가질 때만 비로소 복잡성을 헤쳐나갈 수 있으며, 이는 팀에서 확신을 갖고 결합할 수 있는 상세 요소라는 결과로 나타난다.

Chapter

3부 더 심층적인 통찰력을 향한 리팩터링

Part III: Refactoring Toward Deeper Insight

  • 유용한 모델을 성공적으로 개발하기 위해 명심해야 할 세 가지 관건
    • 정교한 도메인 모델은 만들 수 있으며, 노력을 들일 만한 가치가 있다.
    • 해당 도메인을 학습하는 개발자와 도메인의 전문가의 긴밀한 참여반복적인 리팩터링 과정 없이 유용한 모델을 개발하기란 쉽지 않다.
    • 유용한 모델을 효과적으로 구현하고 사용하려면 정교한 설계 기술이 필요할지도 모른다.

리팩터링 수준

Levels of Refactoring

시스템의 생존력에 가장 큰 영향을 미치는 리팩터링은
(기술적인 관점보다)
도메인에 대한 새로운 통찰력을 얻었을때 수행하거나
코드를 사용해서 모델이 표현하고자 하는 바를 명확하게 드러내고자 수행하는 경우다.
(= 심층 모델을 향한 리팩터링)

리팩터링의 목표는 개발자가 단순히 코드가 수행하는 바를 이해하는 것뿐만 아니라
왜 그렇게 수행되는지를 이해하고 도메인 전문가와의 의사소통에 이를 연관시키는 것이다.

심층 모델

Deep Models

도메인의 피상적1)인 측면은 배제하고
도메인 전문가의 주요 관심사가장 적절한 지식을 알기 쉽게 표현하는 모델이다.
이 정의가 추상화를 의미하는 것은 아니다.
심층 모델이 일반적으로 추상적인 요소를 포함하기는 하지만
문제의 핵심을 관통하는 구체적인 요소 또한 포함할 수 있다.

도메인과 조화를 이루는 모델에서는 융통성, 단순함, 설명력을 얻을 수 있다.
그러한 모델이 공통적으로 지니고 있는 한 가지 특징은 업무 전문가가 즐겨 쓰는 단순하지만 충분히 추상적인 언어가 존재한다는 것이다.

심층 모델/유연한 설계

Deep Model/Supple Design

10 유연한 설계

Supple Design은 변경을 촉진할 뿐 아니라 모델 자체의 개선에도 기여한다.
Model-Driven Design을 지탱하는 두 개의 축이 있다.
심층 모델은 설계의 표현력을 부여한다.
그와 동시에 개발자가 여러 가지 시도를 할 수 있을 정도로 설계가 유연하고
개발자가 무슨 일이 일어나고 있는지 파악할 수 있을 만큼 설계가 명확하다면
모델의 발견 과정에 통찰력을 제공할 수 있다.

발견 과정

The Discovery Process

Chapter

4부 전략적 설계

Part IV: Strategic Design

Chapter


1) 본질적인 현상은 추구하지 아니하고 겉으로 드러나 보이는 현상에만 관계하는 것
domain-driven_design.1708184337.txt.gz · Last modified: 2024/02/17 15:38 by ledyx