Post

Domain Driven Design - (1)

Posted
By 김우재 14 min read

0. 목차

  1. 도메인 주도 설계란?
  2. 하위 도메인
  3. 멘탈 모델과 도메인 지식
  4. 유비쿼터스 언어
  5. 도메인 모델
  6. 진흑 덩어리
  7. 바운디드 컨텍스트
  8. 컨텍스트 매핑
  9. 서비스 매핑

1. 도메인 주도 설계란?

소프트웨어 및 시스템을 구축하기 위해서는 우선 ‘문제’ 자체를 이해해야 한다.

  • 문제 : 조직의 비즈니스 전략과 소프트웨어를 통해 얻고자 하는 가치를 의미한다.
    • 문제를 이해하려면 그것이 존재하는 ‘맥락’을 이해해야 한다.
  • 비즈니스 도메인 : 기업의 주요 활동 영역, 회사가 제공하는 서비스를 의미한다.
  • 하위 도메인 : 비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위를 의미한다.

2. 하위 도메인

비즈니스 활동의 세분화된 영역, 제공하는 서비스 단위를 의미한다.

2.1. 하위 도메인 유형

하위 도메인 유형에는 크게 3가지가 존재한다.

핵심(Core)

  • 회사가 경쟁력을 갖추기 위해서 경쟁 업체들과 차별점으로 수행하고 있는 것(핵심 BM)
  • 복잡성은 높은 경우일 가능성이 높지만 비즈니스에 대한 경쟁력을 제공한다.
  • Ex) 우버의 방향에 따른 손님 매칭 서비스, 구글의 검색 순위 알고리즘

일반(Generic)

  • 모든 회사가 같거나 비슷한 방식으로 수행하는 비즈니스 활동
  • 복잡하고 구현하기 어려우나, 경쟁력을 제공하지 않으면 안되는 알려진 영역
  • Ex) 인증, 권한 부여

지원(Supporting)

  • 회사의 비즈니스를 지원하는 다양한 활동들
  • 기능은 간단하며, 경쟁 우위를 제공할 가능성이 적은 것들
  • Ex) 게시판, 단순 ETL 시스템 등등

2.2. 하위 도메인 구현 방법

핵심(Core)

  • 사내에서 주로 구현하며, 조직내의 핵심 인력들에게 할당하는 중요 업무
  • 지속적으로 변경이 예상되므로 가장 진보적인 엔지니어링 기술을 적용할 필요가 있다.

일반(Generic)

  • 이미 만드렁진 제품 혹은 오픈 소스 솔루션을 이용하여 사용한다.

지원(Supporing)

  • 구현 및 유지보수 비용을 고려하여 외부 솔루션을 사용할 가능성이 높다.
  • 사내 예산/비용 등에 의하여 언제든지 자체 구현할 가능성도 존재한다.
  • 정교한 디자인 패턴이나 고급 엔지니어링 기술이 필요 없는 경우가 많다.

2.3. 하위 도메인 식별

  • 이미 존재하는 경우 이에 대한 문서나 커뮤니케이션
  • 회사의 부서 혹은 조직 단위의 형태
  • 응집된 유스케이스의 집합

3. 멘탈 모델과 도메인 지식

  • 도메인 지식(멘탈 모델) : 도메인 전문가가 문제를 생각하는 방식을 의미한다.
  • 문제를 해결하기 위해서는 ‘문제’ 자체를 이해해야한다.(맥락 포함)

3.1. Model Driven Architecture(MDA)

전통적인 모델링 방식인 Model Driven Architecture 는 아래와 같은 과정을 거쳤다.

  1. CIM(Computation Idependet Model) 에플리케이션에 대한 비즈니스 요구사항을 수집한다.
  2. PIM(Platform Idependent model) 도메인 모델에 대한 UML 다이어그램을 작성한다.(특정 기술에 종속적이지 않은)
    작성된 UML 모델은 핵심 비즈니스 서비스와 컴포넌트를 나타낸다.
  3. PSM(Platform Specific model) 애플리케이션에 대한 특정 기술과 관련한 UML 모델을 작성한다.
  4. Code 애플리케이션 코드를 만들어낸다.

3.2. Domain Driven Design

  • 유비쿼터스 언어 : 도메인 지식을 변환하는 대신 도메인을 설명하기 위한 단일화된 체계
  • 비즈니스 도메인에 관련된 용어, 기술 용어는 지양해야한다.

4. 유비쿼터스 언어

  • 정확하고 일관성 있는 용어, 모호한 용어는 안 된다.
  • 정확한 의미는 맥락에 따라 사람과의 상호 작용에 따라 다르다.
  • 정책 -> 규제/규칙/계약과 같이 명확하게 정의해야한다.
    • 동의어(X)
    • 사용자(X) -> 방문자, 계정

5. 도메인 모델

  • 효과적인 모델은 그 목적을 달성하는데 필요한 세부사항만 포함한다.
  • 실 세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 한다.
  • All Models are Wrong, Some are Usefule
  • 모델은 본질적으로 추상화의 결과이다.(꼭 일치할 필요 없이 맥락에 맞게 추상화)
  • 모델로써 실세계의 복잡성을 관리한다.
  • 도메인 모델링 : 유비쿼터스 언어로 사실상 비즈니스 도메인 모델을 구축하는 것이다.
  • 명사와 행위 파악

6. 진흑 덩어리

  • 소프트웨어의 복잡성은 본질적인 도메인 복잡함과 우발적인 기술 복잡성의 혼합의 결과물
    • 용어 충돌, 모호성
    • 예시) 거대한 ERD
    • 해결 방법 : Context(주제 영역) 를 나누자!
  • Bounded Context :
    맥락의 경계, 유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음
    각 언어를 적용할 수 있는 명시적인 Bounded Context 에 할당한다.

7. 바운디드 컨텍스트

  • 도메인 모델의 경계를 의미한다.
  • 유비쿼터스 일관성이 유지되는 경계이다.
  • 유티쿼터스 언어의 용어, 원칙, 비즈니스 규칙은 해당 바운디드 컨텍스트 내에서만 일관성이 있다.
  • 즉, 유비쿼터스 언어는 바운디드 컨텍스트내의 도메인 주요 개념을 표현하기 위해 도메인내에서만 사용하는 공통 언어이다.
  • 예시)
    • 주문 : 주문하는 사람
    • 시스템 : 고객
    • 배송 : 배송 받는 사람

7.1.. 바운디드 컨텍스트와 도메인 모델

  • 도메인 모델 : 특정 도메인을 개념적으로 표현한 것
    • 도메인의 핵심 규칙을 구현한 것이다.
    • 바운디드 컨텍스트가 이후 세분화 될 수 있다.
      • 컴포넌트 개발 생명주기 분리할 필요가 있거나 기능이 독립적으로 확장해야 할 경우
    • 각 바운디드 컨텍스트의 수명 주기는 독립적이다.
    • 물리적 경계 역할, 소유권 경계
  • 바운디드 컨텍스트와 하위 도메인의 차이
    • 하위 도메인은 비즈니스 전략에 의해 정의된다.
    • 바운디드 컨텍스트는 소프트웨어 엔지니어에 의해 설계된다.
    • 하위 도메인은 발견하고, 바운디드 컨텍스트는 설계한다는 점이다.
    • 큰 도메인 모델을 별개의 바운디드 컨텓스트로 분리한다.

8. 컨텍스트 매핑

  • 바운디드 컨텍스트는 서로 독립적으로 발전할 수 있지만, 상호작용 해야한다.
  • 즉, 각각의 바운디드 컨텍스트는 접점이 있다는 뜻인데 이를 Contract 라고 한다.
  • 바운디드 컨텍스트의 연동, 통합 :
    각 바운디드 컨텍스트에서 작업하는 팀간의 관계를 의미하기도 한다. 이 과정에서 서로간의 유비쿼터스 언어에 대한 통역, 동기화 같은 작업이 필요하다.
    • 협력형 패턴 그룹
    • 시용자-제공자
    • 분리형 노선
    • 기타 등등

8.1. 협력형 패턴 / 파트너쉽 패턴

  • 바운디드 컨텍스트가 굉장히 밀접할 때
  • 단순 의사소통으로도 해결이 가능하다.

8.2. 협력형 패턴 / Shared Kernel

  • 바운디드 컨텍스트에서 서로간의 공용 영역이 존재한다.
  • 공용 모듈 및 이를 함께 관리함으로서 해결한다.
  • 단, 공유 영역은 최소한으로 가져가고자 노력해야한다.

8.3. Spplier-Customer / Upstream, Downstream

  • 공급자와 소비자로 나뉘어, 소비자가 공급자로부터 어떠한 정보를 받는다.

8.4. Spplier-Customer / Conformist

  • 순응주의자.
  • 하위 팀에서 상위 팀의 모델을 그대로 사용하는 방식
  • 힘의 균형은 상류에 존재한다.

8.5. Spplier-Customer / Anti-Corruption Layer

  • ACL(충돌방지계층)
  • 하류가 상위에서 제공하는 모델에 대해서 순응하지 않는 경우
  • ACL 에서 모델을 변환하여 사용하는 패턴(주로 레거시에서 사용)

8.6. Spplier-Customer / Open Host Service

  • OHS(오픈 호스트 서비스)
  • 힘이 사용자(하류) 측에 있을 경우, 제공자는 사용자를 보호하고 가능한 최고의 서비스를 제공한다.
  • 여러 사용자에 따른 버전 관리 가능해야 한다.

8.7. Spplier-Customer / Public Language

  • 공개 프로토콜, 공표된 언어(PL)
  • 명세를 전달한다.

8.8.Seprate Ways

  • 각자의 길
  • 커뮤니케이션의 어려움
  • 협력과 연동보다는 특정 기능을 중복으로 두는 것이 더 저렴한 경우다.

9. 서비스 매핑

  • [핵심 서브 도메인] == ACL —— OHS/PL – [일반 서브 도메인 칸텍스트]
  • [핵심 서브 도메인] == ACL —— OHS/PL – [지원 서브 도메인 컨텍스트]
  • [지원 서브 도메인 컨텍스트] == ACL —— OHS/PL – [일반 서브 도메인]
Blogging, Tech
Architechture Pattern
This post is licensed under CC BY 4.0 by the author.