[도메인 주도 설계 첫걸음] Part 1. 비즈니스 도메인 분석하기

본문은 도메인 주도 설계 첫걸음을 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다.

 

1장) 비즈니스 도메인 분석

비즈니스 도메인

• 기업의 주요 활동 영역
• 기업은 여러 비즈니스 도메인을 운영할 수 있음
• 비즈니스 도메인은 자주 변경될 수 있음 (e.g. 노키아)

 

하위 도메인

하위 도메인

• 비즈니스 활동의 세분화된 영역
• 핵심, 일반, 지원의 세 가지 유형으로 구분

핵심 하위 도메인

• 회사가 경쟁업체와 다르게 수행하고 있는 것 (e.g. 구글의 검색 알고리즘)
• 핵심 하위 도메인은 복잡성이 높음
• 핵심 하위 도메인은 경쟁 우위의 원천이 됨

일반 하위 도메인

• 모든 회사가 같은 방식으로 수행하는 비즈니스 활동

지원 하위 도메인

• 회사의 비즈니스를 지원하는 활동
• 지원 하위 도메인은 어떠한 경쟁 우위도 제공하지 않음

하위 도메인 유형	경쟁 우위	복잡성	변동성	구현 방식	문제
핵심	예	높음	높음	사내 개발	흥미로움
일반	아니오	높음	낮음	구매/도입	해결됨
지원	아니오	낮음	낮음	사내 개발/하청	뻔함

 

하위 도메인 경계 식별

• 하나의 하위 도메인은 분석을 통해 여러 핵심 하위 도메인, 지원 도메인, 일반 하위 도메인으로 나눠질 수 있다 (경계 식별)
• 핵심 하위 도메인에는 경계 식별을 위한 노력이 많이 필요하다
• 반면 지원 및 일반 하위 도메인의 경우에는 이러한 식별 작업이 비교적 적게 필요하다

 

도메인 전문가

• 소프트웨어의 비즈니스 도메인에 대한 권위자
• 일반적인 도메인 전문가는 요구사항을 제시하는 사람 or 소프트웨어의 최종 사용자

---

2장) 도메인 지식 찾아내기

비즈니스 문제

• 비즈니스 도메인 컨텍스트에서 ‘문제’의 의미는 광범위함
• 비즈니스 문제는 비즈니스 도메인과 하위 도메인의 모든 수준에서 발생할 수 있음
• 하위 도메인은 세분화된 문제 도메인(problem domain)으로 특정 비즈니스 기능에 대한 솔루션을 제공하는 것이 목적

 

도메인 지식 찾아내기

• 도메인 전문가를 이해하고 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이 중요하다
• 즉, 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 커뮤니케이션이 있어야 효과적인 지식 공유가 가능하다

 

유비쿼터스 언어

• 도메인 지식은 그 전달 과정에서 종종 왜곡된 상태로 전달되는 경우가 있다
• 비즈니스 도메인을 설명하기 위한 단일화된 언어 체계가 바로 유비쿼터스 언어이다
  • 모든 프로젝트 참가자의 공통된 이해는 오직 유비쿼터스 언어와 그 용어의 지속적인 사용을 통해서만 함양될 수 있다
  • 유비쿼터스 언어는 비즈니스 언어이므로 기술 용어는 제외하고 비즈니스 도메인에 관련된 용어로만 구성해야 한다
  • 유비쿼터스 언어는 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현하는 것이 목표이다
  • 유비쿼터스 언어의 모든 용어는 일관성이 있어야 하며, 모호하지 않고 동의어가 없어야 한다
• 유비쿼터스 언어는 비즈니스 도메인 모델링과 같다
  • 모델이란? 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보가 제공해야 한다
  • 도메인 전문가의 사고 프로세스인 멘탈 모델을 포착해야 한다
  • 필요한 만큼의 비즈니스 도메인 관점을 포함하면 된다
• 용어집과 거킨 테스트 같은 도구는 유비쿼터스 언어를 문서화하고 유지보수하는 데 도움이 된다
• 그러나 가장 중요한 것은 지속적으로 언어를 사용하는 것이다

---

3장) 도메인 복잡성 관리

바운디드 컨텍스트

• 유비쿼터스 언어의 일관성이 유지되는 경계
  • 유비쿼터스 언어의 용어, 원칙, 비즈니스 규칙은 해당 바운디드 컨텍스트 내에서만 일관성이 있음
  • 유비쿼터스 언어는 명시적으로 적용 가능한 컨텍스트 없이 정의하거나 사용이 불가능
• 쉽게 말해 모델의 경계

바운디드 컨텍스트 vs 하위 도메인

• 바운디드 컨텍스트 vs 하위 도메인 = 소프트웨어 설계 vs 비즈니스 전략
  • 하위 도메인은 발견하고, 바운디드 컨텍스트는 설계한다 → 도메인은 문제 영역이고, 바운디드 컨텍스트는 해결 영역이다!
• 바운디드 컨텍스트는 여러 하위 도메인을 포함할 수 있다
  • 바운디드 컨텍스트와 하위 도메인의 설계는 1:1이 될 수 있지만, 1:1로 제한해버리면 유연성이 떨어진다

 

경계

물리적 경계

• 바운디드 컨텍스트는 물리적 경계 역할도 한다
  • 각 바운디드 컨텍스트는 개별 서비스/프로젝트로 구현돼야 한다
  • 서로 다른 생명주기를 지닌다
• 바운디드 컨텍스트가 여러 하위 도메인을 포함할 경우, 바운디드 컨텍스트는 물리적 경계가 되는 반면 하위 도메인은 논리적 경계(e.g. 네임스페이스, 모듈, 패키지)가 된다

소유권 경계

• 바운디드 컨텍스트는 한 팀에서만 구현, 발전 유지 관리해야 한다
• 단일 팀이 여러 개의 바운디드 컨텍스트를 소유할 수 있다

---

4장) 바운디드 컨텍스트 연동

• 하나의 바운디드 컨텍스트 내의 언어는 특정 문제를 해결하는 비즈니스 도메인을 모델링한다
• 다른 바운디드 컨텍스트의 모델은 서로 독립적으로 발전하고 구현될 수 있지만, 바운디드 컨텍스트 자체가 독립적인 것은 아니다
• 바운디드 컨텍스트는 항상 접점이 있는데, 이것을 컨트랙트(contract)라고 부른다
  • 각 컨트랙트는 하나 이상의 당사자에 영향을 끼치므로 서로 조율해서 컨트랙트를 정의해야 한다
• 바운디드 컨텍스트가 다르면 사용하는 유비쿼터스 언어가 다르다
  • 그렇다면 연동이 필요할 때 어떤 언어를? 연동에 대한 고민은 솔루션 설계에서 평가되고 다뤄져야 한다
• 바운디드 컨텍스트 간의 관계와 연동을 정의하는 도메인 주도 설계 패턴은 바운디드 컨텍스트에서 작업하는 팀 간의 협력적 특성에 의해 주도된다
  • 이러한 패턴은 협력, 사용자-제공자, 분리형 노선의 세 그룹으로 나뉜다

 

협력형 패턴 그룹

• 협력형 그룹의 패턴은 소통이 잘 되는 팀에서 구현된 바운디드 컨텍스트와 관련있다
  • 단일 팀에 의해 구현된 바운디드 컨텍스트
  • 한 팀의 성공이 다른 팀의 성공에 달려있고, 그 반대도 마찬가지인 팀
• 커뮤니케이션과 협업의 매우 중요한 팀

파트너십 패턴

• 바운디드 컨텍스트 간의 연동은 애드혹(ad-hoc) 방식으로 조정한다
  • 한 팀은 다른 팀에게 API의 변경을 알리고 다른 팀은 충돌 없이 이를 받아들인다
• 연동의 조정은 양방향에서 한다
  • 양 팀 모두 협력할 뿐, 방해하지 않는다
• 동기화와 커뮤니케이션의 어려움 때문에 지리적으로 떨어져 있는 팀에게는 적합하지 않을 수 있다

공유 커널 패턴

• 바운디드 컨텍스트가 모델의 경계지만, 여전히 하위 도메인의 동일 모델 또는 그 일부가 여러 다른 바운디드 컨텍스트에서 구현되는 경우가 있다
• 공유 모델은 이를 사용하는 모든 바운디드 컨텍스트에 걸쳐서 일관성을 유지해야 한다
• 최대한 공유되는 범위를 최소화해야 하며, 변경이 생길 때마다 모든 바운디드 컨텍스트와 연동 테스트를 수행해야 한다
• 공유 커널 패턴은 동일 팀에서 소유하고 구현한 바운디드 컨텍스트를 연동하는 경우에 잘 맞는다
• 주의사항
  • 바운디드 컨텍스트 간에 강한 의존관계를 만드므로 중복 비용이 조율 비용보다 클 경우에만 적용해야 한다
  • 이 패턴은 단일 팀 원칙을 위반하는 것으므로 신중하게 고려해야 하는 실용적인 예외라고 할 수 있다
  • 결국 앞서 말한 것처럼 공유되는 범위를 최소화하고, 매 변경 시마다 통합 테스트를 수행하는 것이 중요하다

 

사용자-제공자 패턴 그룹

• 서비스 제공자는 업스트림, 고객 또는 사용자는 다운스트림
• 협력 그룹과 다르게 양 쪽은 서로 독립적으로 성공할 수 있다
• 그러나 실제론 권력의 불균형이 존재하여 업스트림 또는 다운스트림의 팀이 연동 컨트랙트를 주도한다

순응주의자 패턴

• 힘의 균형이 서비스를 제공하는 업스트림 팀에 있는 경우
• 다운스트림 팀이 업스트림 팀의 모델을 그대로 받아들이는 바운디드 컨텍스트의 관계
• 제공자의 모델에 따라 정의된 연동 컨트랙트를 제공

충돌 방지 계층 패턴

• 힘의 균형이 업스트림 서비스에 있지만, 다운스트림 바운디드 컨텍스트가 이에 순응하지 않는 경우
  • 순응에 필요한 노력이 가치가 없는 경우
    • 다운스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함할 경우
    • 업스트림 모델이 사용자의 요건에 비효율적이거나 불편한 경우
    • 제공자가 컨트랙트를 자주 변경하는 경우
• 충돌 방지 계층(ACL: anticorruption layer)을 통해 업스트림 바운디드 컨텍스트의 모델을 스스로의 필요에 맞게 가공할 수 있다

오픈 호스트 서비스 패턴

• 힘이 사용자 측에 있을 경우
• 업스트림 제공자는 퍼블릭 인터페이스와 구현 모델을 분리
• 제공자의 퍼블릭 인터페이스는 자신(업스트림)의 유비쿼터스 언어를 따르는 대신, 연동 지향(integration-oriented language)를 통해 사용자에게 더 편리한 프로토콜을 노출하려 한다
  • 이러한 프로토콜을 공표된 언어(published language)라고 한다
• 오픈 호스트 서비스(OHS: open-host service) 패턴은 충돌 방지 계층 패턴의 반대
  • 사용자 대신 제공자가 내부 모델 번역을 구현한다

 

분리형 노선

• 전혀 협력하지 않는 것
• 팀에 협업 의지가 없거나 협업할 수 없는 경우 등 다양한 케이스가 존재
  • 커뮤니케이션 이슈
  • 일반 하위 도메인
    • 일반 하위 도메인이 일반 솔루션과 연동하는 것이 쉽다면 각 바운디드 컨텍스트 내에서 각자 연동하는 것이 더욱 비용 효과적 (e.g. 로깅 프레임워크)
      • 로깅 프레임워크는 바운디드 컨텍스트 내의 모든 하위 도메인이 사용하지만, 공유 모델로 만드는 것보다 일반 솔루션을 사용한다
• 모델의 차이
  • 모델이 너무 달라서 중복을 감안하고 가는 게 나은 경우

 

컨텍스트 맵

• 컨텍스트 맵은 시스템의 바운디드 컨텍스트와의 연동을 시각적으로 표현
• 장점
  • 거시적 설계 관점, 커뮤니케이션 패턴, 조직 문제에 대한 통찰력을 얻을 수 있음
• 유지보수
  • 프로젝트 초기부터 도입하는 것이 좋음
  • 다 함께 유지보수하는 것이 Best
  • 각 팀은 자신이 담당하는 외부 바운디드 컨텍스트 연동에 대해 자신한다
  • 컨텍스트 매퍼(Context Mapper) 같은 도구를 사용해서 코드로 관리할 수 있다
• 한계
  • 작성하기 어려움
    • 컨텍스트 내의 하위 도메인이 각각 다르게 연동할 수 있음