도메인 주도 설계(DDD)?

기존 프로세스의 문제점

• 시장조사 => 서비스 기획 => 베타서비스 개발 => 마케팅 => 수정기획 => 서비스 개발 => 마케팅

• 이중 수정기획 => 서비스 개발 => 마케팅 부분은 무한으로 돌아간다.

• 기획과 개발의 불일치가 발생한다.

• 기획자, 마케터, 개발자, 디자이너는 각자 자신의 일을 하고 PM이 이 직군의 사람들을 조율한다

• 각자의 관점(중요도)이 너무 다르기때문에 의사소통도 힘들고 프로젝트가 완성되기까지의 충돌이 많다. 또한 서로의 생각을 상대방에게 이해시켜야 하는 의사소통 비용이 너무 많이 들어간다.

• 따라서 PM의 역할이 너무나도 크다

• 그 분야의 도메인(영역)지식을 기반으로 추상화 하여 모델(설계도)을 만들고 이것을 기반으로 소프트웨어가 개발된다.

해결방안

UBIQUITOUS LANGUAGE(보편언어)

• 기획자, 개발자, 분석가 들이 공통적으로 이해할 수 있는 언어를 정의하고 사용하자
• 즉 쉽게 이야기하고 전문용어를 최소화 하는것도 하나의 방법

모델주도 설계

• 도메인 분석과 설계의 간극을 최소화
• 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지한다
• 모델 = 코드

정리

도메인 주도 설계

• 소프트웨어가 복잡한 이유는 도메인이 복잡하기 때문이다
  따라서 보편언어와 모델주도 설계를 적용한다.

도메인?

• 영역, 집합
• 비지니스 Domain을 의미
• 예를 들어 주문, 고객, 주소관리 등등과 같이 분리한다.
  (3가지 영역으로 나누었음)

DDD의 2가지 종류

전략적 설계

• 비지니스의 상황(context: 대상자, 상황)에 맞게 설계
• 모든 Context(상황)를 이벤트 스토밍을 통해 공유
  모든 일어날수 있는 이벤트 경우의 수를 전부 생각해보자~
• 각 Context를 그룹핑(Bounded Context)
  너무 많으니깐 카테고리별로 분류를 하자~
• 컨텍스트 매핑을 통해 Bounded context 간의 관계를 정의
  분류된 Bounded context들끼리의 관계를 정의 한다.

DDD는

단순히 Entity, Value object, aggregate와 같은 구체적인 개념이라기보단 프로세스에 대한 철학이다.(포괄적인 개념)