Domain Driven Design – 1부 (Strategic Design)

Domain Driven Desing

도메인 주도 디자인이란 도메인이 중심이 되는 개발 방식을 말하며,

요구 사항을 모으는 것부터 low_level 디자인까지 소프트웨어 개발의 라이프사이클 전체를

포함하는 방법론 이라고 할 수 있습니다.

DDD의 목적은 소프트웨어의 연관된 부분들을 연결하여 계속 해서 진화하는

모델을 만들어 나가 복잡한 어플리케이션을 쉽게 만들어 가는 것에 있습니다.

즉, Loose Coupling과 High Cohesion으로 보다 가벼운 설계로 소프트웨어의 위기와

커뮤니케이션 문제를 해결하기 위해 탄생하였습니다.


DDD의 세가지 주요 원리

  • 도메인 그 자체와 도메인 로직에 초점을 맞춥니다.

– 일반적으로 많이 사용하는 데이터 중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말합니다.

  • 보편적인(ubiquitous) 언어의 사용– 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있고 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정을 말합니다.

이로서 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식으로 커뮤니케이션이 가능해집니다.

  • 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것입니다.

– 분석 모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것이 DDD의 핵심원리입니다.


DDD는 Strategic Design과 Tactical Design으로 단계를 나눌수 있습니다.

  • 전략적 설계 – 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트(bounded context)로 정의하고 경계의 관계를 컨텍스트 맵(context map)으로  정의.
  • 전술적 설계 – 전략적 설계에서 도출된 바운디드 컨텍스트와 도메인을 이용하여 애그리거트 패턴, 엔티티와 값 객체, 레포지토리, 등을 구성하고 구현.

1부. Strategic Design

소프트웨어를 디자인 할 때 객체를 기준으로 디자인을 진행하는 것은 Object Oriented Design 이라고 하는데,이러한 관점에서 볼 때 Strategic Design은 OOD가 잘 이루어진 것으로 볼 수 있습니다.

Strategic Design이란 Context 에 대해 생각하고 이를 기준으로 디자인을 하는 것을 말합니다.

여기서 Context 란 특정 객체 혹은 상황이 벌어지는 주변 환경을 말합니다.

가장 쉬운 예로 가게 안에 접시에 담긴 피자와 혹은 길에 버려진 피자를 생각해 봅시다.

같은 피자이지만 피자가 매장 안의 접시에 있는지 혹은 길에 있는지에 따라 유료, 무료의 차이가 생기게 되고 사실상 다른 것으로 간주될 수 있습니다.

이처럼 같은 사물이나 행동 양상이 벌어지는 상황에 집중하여 디자인을 하는 것이 Strategic Design 의 핵심이라고 할 수 있습니다.

Strategic Design을 이해하기 위해 간단한 예로 주택을 짓는 경우를 생각해 봅시다.

우리가 원하는 집을 짓기 위해서 우리가 하는 행동 절차는 다음과 같습니다.

  1. 어떤 주택을 지을지 생각을 해 본다.
  2. 그런 뒤에 우리는 Domain Expert 즉, 이 경우 집 전문가와 상의를 한다.
  3. 주택을 지을 때 어떤 핵심적인 가치에 집중하여 집을 지을지를 선택합니다. 가령 헛간이 넓어야 한다던가, 수영장이 커야 한다던가 중점적인 사항을 명시합니다.
  4. 그 뒤 우리는 이미 지어진 다른 집들을 최대한 많이 조사하여 마음속에서 원하는 집의 형상을 떠올려 봅니다.
  5. 그런 뒤에 우리는 그 형상을 실제 집으로 만들어 내기 위해 모델링을 하고
  6. 이를 토대로 구체적인 설계도를 그려 나갑니다. 이 설계도에는 집의 아주 구체적인 부분들이 명시되게 됩니다.

이렇게 DDD를 통한 설계 과정에서 사용되는 용어는 다음과 같습니다.

  • 먼저 집 전체에 대한 설계의 전체를 우리는 domain 이라고 부르며, 커다란 집의 각각의 부분 집합인 헛간, 농장, 수영장 등 큰 파트들을 subdomain 이라고 부릅니다.
  • 또 각각의 subdomain에 대해 각 subdomain의 문맥적 상황을 bounded context 라고 부르며, 실제 subdomain의 구체적인 형상을 나타내는 것을 domain model 이라고 부릅니다.
  • 여기서 bounded context 가 가지는 의미는 바로 특정 모델이 어떤 bounded context 에 속하는 가에 따라서 다른 의미를 가지기 때문입니다.
  • 가령, 주택 건축시에 정문에서 caretaker라는 모델이 있다면 이는 바로 경비원을 말하는 것일 겁니다.하지만 caretaker라는 단어가 메인 주거 건물 안에서 가지는 의미는 이와 다를 수 있습니다.하지만 caretaker라는 단어가 메인 주거 건물 안에서 가지는 의미는 이와 다를 수 있습니다.

 * 정리

Context의미를 결정하는 것 처럼 보이는 단어 나 문장이 나타나는 설정으로,모델에 관한 문장은 context 안에서만 이해될 수 있습니다.주택을 구성하는 각 부분 구간들에 대한 환경을 말합니다.
Model도메인의 특정 양상을 묘사하는 추상화 시스템으로 도메인과 관련된 문제를 해결하는 데 사용됩니다.
Ubiquitous Language소프트웨어를 만들기 위해서는 많은 사람들이 원활히 소통해야 하고 여기에는 다양한 용어들이 사용됩니다.가령, 기획자, 디자이너, 개발자가 모인 자리에서 각자 서로의 언어로 대화를 한다면 이는 원활한 커뮤니케이션을 심각하게 저해하게 됩니다.이 경우에 필요한 것이 Ubiquitous Language이며 이는 domain model 을 둘러싼 언어구조를 말합니다.이 언어는 팀 전체가 각각의 업무 파트에서 공통적으로 사용될 수 있어야 하며, 실제 개발의 측면에서 모든 기획자, 디자이너, 개발자가 공통된 어휘를 사용해야 서로간에 이견이 없을 것이며 이러한 공통된 어휘를 ubiquitous language라고 합니다.
Bounded Context위에서 설명한 Context에 대한 구체적인 설명으로, 특정 모델이 정의되고 적용될 수 있는 영역을 이야기 합니다.주택을 짓는 경우에 빗대어 생각해 볼 때, Bounded Context는 주택 전체를 구성하는 헛간, 농장, 수영장, 메인 주택 등의 큰 요소들 각각을 둘러싼 상황을 의미합니다.특정 모델은 어떤 bounded context에 놓이는가에 따라 다르게 이해될 수 있습니다.실제 소프트웨어를 구축함에서의 예를 들면 가령 sales를 담당한하는 subdomain이 있을 수 있고,이를 지원하는 support와 accounting 라는 subdomain 이 존재할 수 있습니다.이러한 각각의 subdomain이 놓인 환경인 bounded context 내에서 특정 모델 customer 가 보여지는 시각은 매우 상이할 수 있습니다.sales 팀에서 고객을 보는 시각은 주로 사회적 관심사, 좋아하는 것, 욕구 등의 것일 겁니다.하지만 accounting의 측면에서는 사용자는 그저 하나의 계정으로써 그 사람의 결제정보 만이 중요한 정보일 수 있습니다.즉 각기 다른 bounded context에서 ubiquitous language는 비록 표현은 같지만 다른 의미를 가지게 됩니다.
Context Map각 bounded context들 사이의 관계를 말하며 즉, 주택 건축시에 헛간, 뒷간, 수영장 등 큰 요소들이 어떤식으로 서로 연관이 되어 있는지를 나타냅니다.
Domain ModelDomain Model 이란 실제 세계를 반영하는 구체적인 설계로, 주택 건축시에 주택을 구성하는 메인 주택의 구체적인 설계도를 말합니다.

참고사이트

댓글 남기기