[DDD 첫걸음] 1-3. 전략적 설계 - 도메인 복잡성 관리.

우리의 목표는 유비쿼터스 언어를 사용하여 소프트웨어 설계의 의사결정을 내리는 것이기 때문에 언어는 명확하고 일관성이 있어야 한다.

따라서 모호성, 암묵적인 가정, 관련 없는 세부사항이 없어야한다.

 

하지만 조직의 규모에 따라 도메인 전문가의 멘탈 모델은 일관성이 없을 수 있다.
즉, 같은 비즈니스 도메인에서도 도메인 전문가마다 서로 다른 모델을 사용할 수 있다.

 

일관성 없는 모델

도메인 전문가의 언어에서 리드(lead)라는 용어가 마케팅과 영업부서에서 서로 다른 의미로 사용됨

예시) 리드 (Lead) 컨텍스트

• 마케팅 부서
  - 마케팅 담당자에게 리드는 누군가가 제품 중 하나에 관심이 있다는 알림을 나타냄.
  - 잠재고객의 연락처 정보를 수신하는 이벤트는 리드로 간주.
• 영업부서
  - 리드는 영업 프로세스의 전체 수명주기를 나타냄.
  - 단순한 이벤트가 아니고 장기적으로 진행되는 과정.

우리는 유비쿼터스언어는 일관성이 있어야 함을 알고있지만, 위의 경우는 도메인 전문가에 따라서 리드라는 용어의 차이가 있음을 알 수 있다. 특히 소프트웨어(소스코드)는 모호성을 잘 대처하지 못한다. 영업부서의 복잡한 모델을 마케팅 부서에 적용하면 필요하지 않은 곳에서 복잡성을 키우게 될 것이다.(Over engineer) 반대로 마케팅의 단순한 모델에 맞추기 위해 영업 프로세스를 단순화 하는 것은 영업 하위 도메인 요구에 맞지 않을 것이다.(Under engineer)

해결책과 문제점

1. 이 문제에 대한 전통적인 솔루션은 모든 종류의 문제에 사용할 수 있는 단일 모델을 설계하는 것.
   - "이것저것 다 잘하는 사람은 단 한 분야에서도 달인이 될 수 없다. (Jack of all trades, master of none)"
   - 이러한 모델은 모든 것에 적합해야 하지만 결국에는 아무 소용이 없다. 결국 복잡성이 발목을 잡는다.
   - 관련 없는 세부사항을 필터링하는 복잡성. 필요한 것을 찾는 복잡성. 데이터를 일관된 상태로 유지해야하는 복잡성.
2. '마케팅 리드', '영업 리드'와 같이 문맥상 정의에 문제가 있는 용어 앞에 접두사를 추가하는 것. 
   - 이 방법의 문제점은 인지부하를 유발한다. 즉 각 모델을 언제 사용하고 충돌하는 모델을 계속해서 구현할 수록 실수하기 쉬움.
   - 모델의 구현이 유비쿼터스 언어와 일치 하지 않음. (아무도 대화에서는 접두사를 사용하지 않을 것이기 때문)

 

바운디드 컨텍스트란 무엇인가?

유비쿼터스 언어를 여러 개의 작은 언어로 나눈 다음, 각 언어를 적용할 수 있는 명시적인 바운디드 컨텍스트에 할당하면, 앞선 문제를 해결할 수 있다. 앞의 예에서 마케팅과 영업이라는 두 가지 바운디드 컨텍스트를 식별할 수 있다.

세분화된 유비쿼터스 언어 각각은 일관성을 띠며 도메인 전문가의 멘탈 모델을 따를 수 있다.

 

[도메인 주도 설계 첫걸음] 유비쿼터스 언어를 바운디드 컨텍스트로 분할하여 일관성이 없는 문제 해결

바운디드 컨텍스트 패턴을 사용하면 컨텍스트를 명시적이고 중요한 비즈니스 도메인의 요소로 모델링할 수 있다.

 

모델 경계

• 우리가 해결하려는 문제는 모델 본연의 목적이다.
• 모델은 경계 없이 존재할 수 없다. 따라서 모델의 경계(바운디드 컨텍스트)를 정의하는 것은 모델링 프로세스의 본질적인 부분임.
• 하나의 바운디드 컨텍스트의 유비쿼터스 언어는 다른 바운디드 컨텍스트의 범위에는 완전히 관련이 없다.
• 바운디드 컨텍스트는 유비쿼터스 언어의 일관성이 유지되는 경계다.
• 유비쿼터스 언어의 용어, 원칙, 비즈니스 규칙은 해당 바운디드 컨텍스트 내에서만 일관성이 있음.

정제된 유비쿼터스 언어

• 바운디드 컨텍스트를 통해 유비쿼터스 언어의 정의를 완성할 수 있다.
• '유비쿼터스'언어가 조직 전체에서 '유비쿼터스'하게 써야된다는 의미가 아님을 명심하자.
• 유비쿼터스 언어는 바운디드 컨텍스트 경계 안에서만 보편적으로 적용된다. (해당 컨텍스트 모델을 설명)
• 유비쿼터스 언어는 명시적으로 적용 가능한 컨텍스트 없이는 정의하거나 사용할 수 없다.

바운디드 컨텍스트의 범위

• 유비쿼터스 언어의 일관성은 해당 언어의 가장 넓은 경계를 식별하는데 도움이 되고, 
  일관성 없는 모델과 용어가 있기 때문에 더 이상 커질 수 없다.
• 유비쿼터스 언어의 범위(바운디드 컨텍스트)를 정의하는 것은 전략적인 설계 의사결정이다.
  경계는 넓힐 수도, 더 작은 문제 도메인으로 쪼갤 수도 있다.
• 바운디드 컨텍스트의 크기 자체는 의사결정 요소가 아님. (모델 크기엔 정답이 없음)
• 다만 유비쿼터스 언어의 경계가 넓을 수록 일관성 유지는 힘들므로 더 작고 관리하기 쉬운 문제 도메인으로 나누는 것은 도움이 될 수 있다.
• 하지만 작게 만들기 위해 노력하는 것은 역효과를 낳을 수 있다. (필요에 따라 나눠야하지 크기 자체에 큰 무게를 두지 말 것)
  -> 작게 설계된 컨텍스트를 합치는 오버헤드는 크다..!
• 큰 바운디드 컨텍스트에서 세분화된 바운디드 컨텍스트를 추출하는 이유.
  • 새로운 소프트웨어 엔지니어링 팀 구성하거나 시스템의 일부 비기능 요구사항을 해결하는 것.
    예) 일부 컴포넌트의 개발 수명주기를 분리해야 하는 경우.
  • 바운디드 컨텍스트의 나머지 기능과 독립적으로 확장 가능하기 때문에 분리.
• 응집된 기능을 여러 바운디드 컨텍스트로 분할하는 것은 주의하자.
  -> 각 컨텍스트가 독립적으로 발전하는 능력이 저해되기 때문. (많은 상황에서 서로 의존적이 됨.)
  -> 비효율적인 부해를 피하기 위해 같은 데이터에서 작동하는 응집된 유스케이스의 집합을 식별하되, 그것을 여러개의 바운디드 컨텍스트로 분해하지 말 것!

 

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

우리는 비즈니스 도메인을 여러 하위 도메인으로 구성하는 법, 비즈니스 도메인을 세분화된 문제 도메인(모델) 또는 바운디드 컨텍스트의 집합으로 분해하는 개념을 살펴보았다. 비즈니스 도메인을 분해하는 두 가지 방법이 중복으로 보일 수 있으나 모두 필요하다. 

 

그 이유를 살펴보자.

하위도메인

• 기업의 비즈니스 전략을 이해하려면 비즈니스 도메인 분석이 필요하다.
• DDD 방법론에 따르면 분석 단계에 다양한 하위 도메인(핵심, 지원, 일반)을 식별하는 작업이 포함된다.
  -> 조직이 일하고 경쟁 전략을 계획하는 방식.
• 소프트웨어 엔지니어로서 우리는 요구사항을 정의하지 않는다. 그것은 비즈니스가 담당한다.
• 소프트웨어 엔지니어는 하위 도메인을 식별하기 위해 비즈니스 도메인을 분석한다.

바운디드 컨텍스트

• 바운디드 컨텍스트는 소프트웨어 엔지니어에 의해 설계된다.
• 모델의 경계를 선택하는 것은 전략적 설계의 의사결정이다.
• 우리는 비즈니스 도메인을 더 작고 관리 가능한 문제 도메인으로 어떻게 나눌지 정한다.

하위 도메인과 바운디드 컨텍스트 사이의 상호작용

• 이론적으로는 단일 모델이 전체 비즈니스 도메인에 적용될 수 있다. (모놀리식)
  -> 소규모에서는 가능한 모델이다!
• 모델이 충돌하면 도메인 전문가의 멘탈 모델을 따라 시스템을 바운디드 컨텍스트로 분해할 수 있음.
  -> 영업/마케팅 컨텍스트.
• 모델이 여전히 크고 유지보수하기 어려운 경우 더 작은 바운디드 컨텍스트로 분해할 수 있다.
  -> 크리에이티브/퍼블리싱/CRM/권한부여/고객 획득/최적화/전화 등등의 컨텍스트.
• 어느쪽이든 이것은 설계에 대한 의사결정임.
• 어떤 시나리오에서는 바운디드 컨텍스트와 하위 도메인 간에 일대일 관계를 맺는 것이 합리적일 수 있고, 다른 분해 전략이 적합할 수도 있음. (즉, 정답이 없다.)
• 중요한 것은 하위 도메인은 발견하고 바운디드 컨텍스트는 설계한다는 점이다.
  -> 하위 도메인은 비즈니스 전략에 의해 정의.
  -> 소프트웨어 엔지니어는 특정 프로젝트의 컨텍스트와 제약 조건을 해결하기 위해 소프트웨어 솔루션과 바운디드 컨텍스트를 설계할 수 있다.
• 각 지도 유형마다 지구에 대한 다른 유형의 정보를 제공하듯, 문제에 따라 동일한 하위 도메인에 대한 다른 모델을 사용하여 해결하는 것이 합리적일 수 있음.

 

경계

 

건축 설계는 시스템 설계다. 시스템 설계는 상황에 맞는 설계다.
본질적으로 경계(무엇이 들어 있는지, 무엇이 밖으로 나가는지, 범위가 무엇인지, 그 사이를 이동하는지)와 균형에 관한 것이다.
내부의 모양을 구성하는 것처럼 외부의 모양도 재구성한다.
- 루스 말란(Ruth Malan) -

 

 

바운디드 컨텍스트 패턴은 물리적 경계와 소유권 경계를 규정하기 위한 도메인 주도 설계 도구다.

 

물리적 경계

• 바운디드 컨텍스트는 모델 경계뿐만 아니라 이를 구현하는 시스템의 물리적 경계 역할도 함.
• 각 바운디드 컨텍스트는 개별 서비스/프로젝트로 구현돼야 한다.
  즉, 구현, 진화, 버전 관리를 각각의 다른 바운디드 컨텍스트와 독립적으로 해야 한다.
• 바운디드 컨텍스트는 여러 하위 도메인을 포함할 수 있다.
• 바운디드 컨텍스트는 물리적 경계고 하위 도메인은 논리적 경계다.
  (논리적 경계는 프로그래밍 언어의 종류에 따라 네임스페이스나 모듈, 패키지 같은 다른 이름을 갖는다.)

소유권 경계

• 팀 간의 평화로운 공존을 위해 모델 경계(바운디드 컨텍스트)를 활용할 수 있다.
• 팀 간의 작업 분배는 바운디드 컨텍스트 패턴을 사용하여 내릴 수 있는 또 다른 전략적 의사결정이다.
• 바운디드 컨텍스트는 한 팀에서만 구현, 발전, 유지 관리해야 한다. 두 팀이 같은 바운디드 컨텍스트에서 작업할 수 없다.
• 단일 팀에서 여러 바운디드 컨텍스트를 소유하는 것은 가능.

[도메인 주도 설계 첫걸음] 컨텍스트와 팀 관계

 

실생활의 바운디드 컨텍스트

실제로 바운디드 컨텍스트는 비즈니스 도메인과 하위 도메인만큼 분명하지는 않지만, 도메인 전문가의 멘탈 모델이 있는 것 처럼 존재한다. 소프트웨어 엔지니어는 도메인 전문가가 다양한 비즈니스 엔티티와 프로세스에 대해 어떻게 생각하는지 의식해야 한다.

 

시맨틱 도메인

• DDD의 바운디드 컨텍스트는 시맨틱 도메인의 사전적 개념에 기반한다고 볼 수 있다.
• Semantic Domain은 의미 영역과 해당 의미를 전달하기 위해 사용하는 단어 영역으로 구분.
  ex) 모니터, 포트, 프로세서라는 단어는 SW와 HW 엔지니어링 시맨틱 도메인에서 서로 다른 의미를 가짐.