From: 마이크로서비스 패턴

DDD 는 도메인을 구성하는 각 하위 도메인(애플리케이션의 문제 공간(problem space)을 가리키는 DDD 용어)마다 도메인 모델을 따로 정의합니다. 하위 도메인은 비즈니스 능력과 같은 방법(비즈니스를 분석하고 상이한 전문 영역을 식별)으로 식별하므로 십중팔구 비즈니스 능력과 유사한 하위 도메인이 도출됩니다. 가령 FTGO 의 하위 도메인은 주문 접수, 주문 관리, 주방 관리, 배달, 재무 등이 있습니다. 좀 전에 식별한 비즈니스 능력과 비슷하죠?

도메인 모델의 범위를 DDD 용어로는 경계 컨텍스트(bounded context, 경계가 분명한 컨텍스트)라고 합니다. 경계 컨텍스트는 도메인 모델을 구현한 코드 아티팩트(code artifact)를 포함하며, 마이크로 서비스 아키텍처에 DDD 를 적용하면 각 서비스(들)가 경계 컨텍스트가 됩니다. 그림 2-9는 각각 자체 도메인 모델을 가진 서비스에 하위 도메인을 매핑한 것입니다.

DDD 와 마이크로서비스 아키텍처는 거의 찰떡궁합입니다. DDD 의 하위 도메인, 경계 컨텍스트 개념은 마이크로서비스 아키텍처의 서비스와 잘 맞고, 마이크로서비스 아키텍처의 서비스 자율팀 개념은 도메인 모델을 개별 팀이 소유/개발한다는 DDD 사고방식과 잘 어울립니다. 자체 도메인 모델을 가진 하위 도메인이라는 개념 덕분에 만능 클래스를 제거하고 서비스로 분해하기가 더 수월해집니다.1

From: 도메인 주도 개발 시작하기

도메인은 소프트웨어로 해결하고자 하는 문제 영역을 의미한다. 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다. 도메인은 다수의 하위 도메인으로 구성된다. 각 하위 도메인이 다루는 영역을 서로 다르기 때문에 같은 용어라도 의미는 달라 질 수 있다. (Ex. 카탈로그 도메인의 상품과, 배송 도메인의 상품)

도메인 모델은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 의미한다.

다음 그림은 일반적인 애플리케이션의 아키텍처이며, 네 개의 영역으로 구성된다.

도메인 계층은 도메인의 핵심 규칙을 구현한다.

From: 도메인 주도 설계 철저 입문

도메인 주도 설계란 이름 그대로 도메인 지식에 초점을 맞춘 설계 기법이다. 도메인은 '영역' 이라는 뜻이다. 특히 소프트웨어 개발에서 말하는 도메인은 '프로그램에 쓰이는 대상 분야' 라는 의미로 쓰인다. 도메인에 포함되는 개념은 시스템의 대상 분야가 무엇인지에 따라 크게 달라진다. (Ex. 회계 시스템, 물류 시스템)

도메인 주도 설계에서는 도메인 개념을 모델링한 모델을 도메인 모델이라고 한다. 모델은 현실에 일어나는 사건 혹은 개념을 추상화한 개념이다. 추상이란 여러 사물 혹은 개념에서 공통적인 것을 뽑아 파악하는 것을 의미한다.

도메인 객체란 도메인 모델을 소프트웨어 형태의 동작하는 모듈로 나타낸 것을 의미한다. 도메인 주도 설계의 진정한 가치가 드러나는 것은 변화에 대응해 소프트웨어를 수정할 때다. 시스템을 장기적으로 운영하기를 원한다면 도메인 주도 설계를 익혀야 한다.

From: 도메인 주도 설계

도메인은 지식이나 영향력, 또는 활동의 영역을 의미한다. 모델은 도메인의 선택된 측면을 기술하고 해당 도메인과 관련된 문제를 해결하는 데 사용될 수 있는 추상 체계를 의미한다.

소프트웨어의 본질은 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. 소프트웨어 도메인이란 사용자가 프로그램을 사용하는 대상 영역을 의미한다. 예를들어 회계 프로그램에서는 화폐와 금융이 도메인에 해당된다.

CORE DOMAIN 은 사용자의 목적에 중심적인 역할을 수행해서 애플리케이션을 차별화하고 가치있게 만드는 모델의 특징적인 부분을 의미한다.

모델을 요약하라. CORE DOMAIN 을 찾아 그것을 지원하는 다수의 모델과 코드로부터 쉽게 구별할 수 있는 수단을 제공하라. 가장 가치 있고 전문화된 개념을 부각시켜라. CORE 를 작게 만들어라. CORE DOMAIN 에 가장 재능 있는 인력을 할당하고 그에 따라 인력을 채용하라. 시스템의 비전을 수행하기에 충분한 심층 모델을 찾고, 유연한 설계를 개발할 수 있게 CORE 에 노력을 쏟아라. 다른 부분에 대한 투자는 해당 부분이 어떻게 정수가 추출된 CORE 를 보조할 수 있느냐로 정당화하라. 어떤 CORE DOMAIN 을 선택하느냐는 본인의 관점에 달렸다.

모델의 가장 근본적인 개념을 식별해서 그것을 별도의 클래스나 추상 클래스 또는 인터페이스로 추출하라. 이 추상 모델이 중요 컴포넌트 간에 발생하는 상호작용을 대부분 표현할 수 있게끔 설계하라. 특화되고 세부적인 구현 클래스는 하위 도메인을 기준으로 정의된 자체적인 MODULE 에 남겨둔 상태에서 이 추상적이면서 전체적인 모델을 자체적인 MODULE 에 배치하라.

From: 마이크로서비스 아키텍처

데이터 모델링은 특정 문제 영역을 처리하기 위해 필요한 데이터 관점에서 사고하는 개념이다. 우선은 비지니스 문제를 해결하는 데 초점을 두고, 그 다음에 지속적으로 기술 영역에 초점을 맞춰야 한다. DDD 는 비지니스 영역에 초점을 맞추는 방법이다.

DDD 는 마이크로서비스 시스템에서 비지니스 문제를 해결할 수 있는 좋은 방법이다. DDD 개념은 마이크로서비스가 탄생하기 전부터 존재했지만, 마이크로서비스와 완벽하게 잘 맞는다.

DDD 는 먼저 비지니스 문제에 초점을 맞춘다. 이를 위해, 첫 번째 단계는 비지니스 영역에서 다른 컨텍스트들을 식별하는 것이다. 그 다음은 컨텍스트간의 경계를 설정하는 것이다. BOUNDED CONTEXT 는 DDD 에서 가장 중요한 요소이다. BOUNDED CONTEXT 는 마이크로서비스의 경게를 설계하는 효과적인 방법이다. DDD 의 BOUNDED CONTEXT 방법을 사용하는 경우, 모델과 데이터 간 불필요한 공유나, 영역간 강한 결합이 이뤄질 가능성이 현저하게 줄어든다.

From: Eternity

DDD 의 슬로건은 단순하다. 유용한 소프트웨어를 개발하고 싶다면 도메인에 귀를 기울 여라. 도메인에 대한 모델을 만들고 이에 대한 이해를 모든 이해관계자들 간에 공유하라.

DDD 는 소프트웨어의 본질적인 문제를 해결하기 위한 분석/설계 기법일 뿐만 아니라 구성원 간의 사회학적인 관계 또한 포괄하고 있다.

객체 지향 프로그래밍을 처음 배웠던 시젃 가장 중요한 원칙은 "객체의 속성을 사용하는 메소드는 해당 객체에 두어라‟였다. 객체 지향 분석/설계를 처음 배웠던 시절 가장 중요한 원칙은 "문제 도메인에 존재하는 개념과 관계를 찾아 이를 반영하는 소프트웨어를 설계하라‟였다. 최소한 위의 두 가지 원칙을 준수함으로써 표현적 차이 Representation Gap 또는 개념적 차이 Semantic Gap – 을 최소화하는 시스템을 개발할 수 있다. 소프트웨어 모델, 즉 코드가 도메인 모델을 떠오르게 하고 도메인 모델을 바탕으로 예측 가능한 방식으로 작동할 경우 두 모델 간의 “표현적 차이가 적다”라고 한다.

POJO 와 DOMAIN MODEL 패턴의 목표는 동일하다. 표현적 차이를 줄이는 것이다.

DDD 는 도메인 모델과 소프트웨어 모델, 즉 코드 갂의 표현적 차이를 최소화하기 위한 접근 방법이다. DDD 를 성공적으로 적용하기 위해서는 기본적으로 두 가지 요소가 갖추어져야 한다. MODEL DRIVEN DESIGN 과 UBIQUITOUS LANGUAGE 이다.

MODEL-DRIVEN DESIGN 의 개념은 간단하다. 도메인 모델을 반영하는 코드를 작성하라. 코드에 나타나는 구조와 용어는 도메인 모델에 기반해야 한다. 도메인에 대한 이해가 바뀐다면 이를 도메인 모델과 코드 양쪽 모두에 반영하라. 만약 모델이 코드를 작성하기에 적합하지 않다면 구현에 적합하도록 모델을 수정하라.

From: Expert One-on-One J2EE Design and Development

객체-지향 설계가 어떤 특별한 구현 기술(J2EE 나 심지어는 Java)보다 더 중요하다.

References

  • 도메인 주도 설계 / Eric Evans 저 / 위키북스
  • 도메인 주도 개발 시작하기 / 최범균 저 / 한빛미디어
  • 도메인 주도 설계 철저 입문 / 나루세 마사노부 저 / 위키북스
  • 마이크로 서비스 아키텍처 / Umesh Ram Sharma 저 / 에이콘
  • Expert One-on-One J2EE Design and Development / Rod Johnson 저 / WROX Press

주석

  1. [RIC] 2.2.3장. ↩