[Domain Driven Design] 1. 도메인이란?

도메인이란?

'온라인 서점'을 예시로 들어보자.

온라인 서점에서 책에 관련된 많은 기능들을 제공한다. 개발자 입장에서 '온라인 서점'은 구현해야 할 소프트웨어의 대상이 된다. 

온라인 서점 소프트웨어는 온라인으로 책을 판매하는 데 필요한 상품 조회, 구매, 결제, 배송 추적 등의 기능을 제공해야한다.

이때 '온라인 서점'은 소프트웨어로 해결하고자 하는 문제 영역에 해당한다. 

 

https://incheol-jung.gitbook.io/docs/study/ddd-start/1

한 도메인은 다시 하위 도메인으로 나눌 수 있다.

온라인 서점'의 하위 도메인 : 카탈로그, 회원, 결제, 배송, 정산 등

 

각 하위 도메인은 각자의 서비스에 맞는 기능을 제공한다. 카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다. 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다. 예를들어, 고객에 물건을 구매하면 주문, 결제, 배송, 혜택 하위 도메인의 기능이 엮이게된다.

 

도메인의 일부 기능은 자체 시스템에서 구현하고, 나머지 기능은 외부 업체의 시스템을 사용하는 경우도 있다.

https://kimyonghwi.github.io/ddd/ddd-start/

소프트웨어가 도메인의 모든 기능을 제공하진 않는다.

도메인마다 고정된 하위 도메인이 존재하는 것은 아니다. 예를들어, 모든 온라인 쇼핑몰이 고객 혜택을 제공하는 것은 아니다.

 

 

도메인 지식 

개발자는 요구사항을 분석하고 설계하여 코드를 작성하며 테스트하고 배포한다. 이 과정에서 요구사항은 첫 단추와 같다. 요구 사항을 올바르게 이해하지 못하면 엉뚱한 기능을 만들게되고, 이는 잘못 개발한 코드가 된다. 잘못 개발한 코드를 수정해서 고치려면 많은 노력이 든다.

 

코딩에 앞서, 요구사항을 올바르게 이해하는 것이 중요하다. 요구사항을 제대로 이해하지 않으면 쓸모없거나 유용함이 떨어지는 시스템을 만들기 때문이다.

 

▶ 요구사항을 올바르게 이해하려면?

개발자가 도메인 지식을 갖추는 것이다. 제품 개발과 관련된 도메인 전문가, 관계자, 개발자가 같은 지식을 공유하고 직접 소통할수록 도메인 전문가가 원하는 제품을 만들 가능성이 높아진다.

 

▶ "Garbage in, Garbage out"

잘못된 값이 들어가면 잘못된 결과가 나온다. 개발자가 도메인 전문가와 직접 소통할수록 요구사항이 변질될 가능성이 줄지만, 도메인 전문가라고 해서 항상 올바른 요구사항을 주는 것은 아니다. 그러므로 개발자는 요구사항을 이해할 때 왜 이런 기능을 요구하는지 또는 실제로 원하는게 무엇인지 생각하고 전문가와 대화를 통해 진짜로 원하는 것을 찾아야한다.

 

 

도메인의 개념에 대해 좀더 알아보자.

[10분 테코톡] 라테의 도메인 주도 설계 

강의 바로가기 : https://www.youtube.com/watch?v=VIfNipL5KkU 

 

 

도메인 주도 설계 (Domain-Driven-Design)

사전적 의미 : domain : 영역, 범위

사용자가 사용하는것, 소프트웨어로 해결하고자 하는 문제 영역 (=비즈니스 영역)

-> 도메인의 복잡성을 조금 더 쉽게 다룰수 있게 도와주는 도구

 

도메인 전문가와 개발자가 나뉘어서 도메인을 분석하고, 모델을 만들고 소프트웨어로 실체화된다.

개발자가 도메인 전문가와 협의하여 만든 모델을 실체화하는 경우 소프트웨어가 기존 모델과 일치하지 않는 경우가 발생할 수 있다. 개발자는 모델이 가지고있는 요구사항, 가치 등을 정확하게 모를 수 있기 때문이다.

 

[1] 유비쿼터스 랭귀지

• 도메인에 대한 어휘를 이해관계자(도메인 전문가, 개발자, 분석가 등)들이 공통적으로 의미를 이해할 수 있도록 정의하는 것

애매모호한 코드

public enum OrderState {
    STEP1, STEP2, STEP3, STEP4, STEP5, STEP6
}

위 단어를 보고 개발자는 머릿속으로 '출고 전'의 상태가 STEP1, STEP2 라고 도메인 지식을 코드로 해석해야한다.

 

도메인 용어를 사용한 코드

public enum OrderState {
    PAYMENT_WAITING, PREPARING, SHIPPED, DELIVERING, DELIVERY_COMPLETED, CANCELED
}

코드의 가독성을 높여서 코드를 분석하고 이해하는데 시간을 줄여준다.

 

이렇게 도메인 주도 설계에서 언어의 중요함을 강조하기 위해 유비쿼터스 언어(ubiquitous language) 라는 요어를 사용했다. 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언얼르 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용한다. 이렇게 하면 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.

 

[2] 모델 주도 설계

• 분석과 설계를 나누지 않으며 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지하는 것
• 모델링을 통해 가져올 수 있는 통찰을 코드에도 적용 (모델 == 코드)

 

[3] 도메인 모델(Domain Model)

• 도메인에 대한 구체적인 설계, 도메인을 개념적으로 표현한 것
• 개념들의 관계를 표현한 모델
• 문제 영역을 시각화

 

[4] 도메인 주도 설계 (DDD; Domain Driven Design)

• 복잡한 소프트웨어는 기술 자체의 복잡성 보다는 도메인 자체의 복잡성에 기인
• 도메인을 가장 잘 아는 사람(도메인 전문가)과 어떻게 협업할 것인지가 가장 중요
• 유비쿼터스 랭귀지, 모델 주도 설계을 통해 협업 

 

[5] 등장 배경

• 데이터에 종속적인 애플리케이션
• 모델링과 개발과의 불일치

 

[6] 데이터 중심적인 접근법

• 기존 개발은 DB 테이블 중심
• 빈약한 도메인 모델
  • Getter와 Setter만으로 구성된 모델
  • 데이터만 가지는 데이터홀더 개념
  • Big Service Layer

-> 모델과 구현(코드)의 불일치가 발생하고 소통의 어려움이 생긴다.

 

 

DDD Overview

https://velog.io/@cks8483/DDDDomain-Driven-Design

 

[1] Strategic Design : 전략적 설계 (개념 설계)

• 복잡한 도메인의 맥락(Context) 경계를 명확히 정의하는 과정
• Bounded Context안의 도메인 모델에서 보편 언어를 개발하는 방법
• 도메인에서 서브 도메인으로 복잡성을 분리 (핵심, 서브 도메인 파악)
• 컨텍스트 맵핑 기술을 활용하여 여러개의 Bounded Context를 통합
• 이벤트 스토밍 기법을 활용해 Bounded Context 식별 
  • 경계를 구체화
  • 이벤트 스토밍이란? Event와 BrainStorming의 합성어로 Domain Expert와 개발 전문가가 함께 모여 워크샵 형태로 진행되는 방법론으로, 시스템에서 발생하는 이벤트를 중심(Event-First)으로 분석하는 기법으로 특히, Non-Blocking, Event-driven한 MSA 기반 시스템을 분석에서 개발까지 필요한 도메인에 대한 빠른 이해를 도모하는데 유리하다.
    • 진행 과정은 참여자 워크숍 방식의 방법론으로 결과는 스티키 노트를 벽에 붙힌 것

http://www.msaschool.io/operation/design/design-three/

 

[2] Tactical Design : 전술적 설계 (구체적 설계)

• 전략적 설계에서 더 상세한 부분(Bounded Context 내부)을 모델링
• Model Driven Design
• 빌딩 블록(패턴)을 사용하여 모델링 (=Aggregate 패턴)
• 계층형 아키텍처를 통해 도메인 모델 분리
• 도메인 이벤트를 통해 도메인을 보다 명확하게 모델링 
  
  • 도메인 이벤트란, 도메인 이벤트란 동일한 도메인의 다른 부분(프로세스 중)을 인식하고자 하는 도메인에서 발생한 이벤트다.
  • 도메인에 관련된 이벤트가 발생했을때, 이 이벤트를 통해서 연관성 있는 도메인을 파악하기가 쉽다.

 

간단하게 생각한다면?