DDD - 에릭 에반스, (2장 의사소통과 언어 사용)

공유된 언어 (Ubiquitous Language)

• 정의
  • 공유된 언어는 도메인 전문가와 개발자 모두가 이해할 수 있는 공통의 언어
  • 이는 도메인 모델링을 통해 형성되며, 코드와 문서를 모두 동일하게 사용한다
• 중요성
  • 공유된 언어는 오해를 줄이고, 팀 내 의사소통을 명확히 하여 일괄된 도메인 지식을 유지하게 한다
  • 모든 팀원이 동일한 용어와 개념을 사용하면, 도메인 모델이 더욱 정확하고 명확하게 정의된다
• 상황 예제
  • 온라인 쇼핑몰 개발팀에서 "고객"이라는 용어를 사용할 때, 팀 내 모든 사람이 "고객"이란 용어를 동일하게 이해해야 한다
  • 고객은 "제품을 구매하는 사람"으로 정의될 수 있으며, 이 정의는 코드, 문서, 회의에서 일관되게 사용된다

  @Entity
  public class Customer {
      @Id
      @GeneratedValue(strategy = GenerationType.IDENTITY)
      private Long id;
  
      private String name;
      private String email;
  
      // 도메인 용어와 일치하는 메서드 이름
      public void placeOrder(Order order) {
          // 주문을 처리하는 로직
      }
  }
  
  

 

바운디드 컨텍스트 (Bounded Context)

• 정의
  • 바운디드 컨텍스트는 특정 모델이 일관성을 유지하며 적용되는 경계
  • 각 컨텍스트 내에서는 고유한 도메인 모델과 용어가 사용된다
• 중요성
  • 큰 시스템을 여러 개의 바운디드 컨텍스트로 나누면, 각 컨텍스트 내에서 복잡성을 관리하기 쉬워진다
  • 또한, 각 팀이 독립적으로 작업할 수 있는 환경을 제공하여 개발 속도를 높이고, 충돌을 줄일 수 있다
• 상황 예제
  • 온라인 쇼핑몰의 "고객 관리"와 "주문 처리"는 서로 다른 바운디드 컨텍스트로 나눌 수 있다
  • 고객 관리 컨텍스트에서는 고객의 정보와 관련된 작업이 수행되고, 주문 처리 컨텍스트에서는 주문과 관련된 작업이 수행된다
  • 각 컨텍스트는 고유한 모델과 용어를 가진다

 

컨텍스트 맵 (Context Map)

• 정의
  • 컨텍스트 맵은 여러 바운디드 컨텍스트 간의 관계를 시각적으로 표현한 다이어그램
  • 이는 시스템 전체의 구조를 이해하고, 각 컨텍스트 간의 상호작용을 명확히 하는 데 도움을 준다
• 중요성
  • 컨텍스트 맵을 통해 시스템의 전체적인 아키텍처를 파악하고, 컨텍스트 간의 의존성 및 통합 방법을 이해할 수 있다
  • 이는 특히 시스템 통합과 협력에 유용하다
• 자세히 알아보기
  • 두 개 이상의 바운디드 컨텍스트가 공통의 모델 일부를 공유
  • 공유된 부분은 엄격하게 관리되며, 변경 시 모든 관련 팀의 동의가 필요

  [컨텍스트 A] <---- Shared Kernel ----> [컨텍스트 B]
  

  Customer-Supplier
  • 한 컨텍스트가 다른 컨텍스트에 의존하는 관계
  • Supplier 컨텍스트는 Customer 컨텍스트의 요구를 충족시키기 위해 모델을 제공

  [Customer 컨텍스트] <---- Uses ----> [Supplier 컨텍스트]
  

  Conformist
  • 한 컨텍스트가 다른 컨텍스트의 모델을 그대로 따른다
  • 이 관계는 Customer 컨텍스트가 Supplier 컨텍스트의 모델을 수정 없이 사용해야 할 때 나타난다

  [Conformist 컨텍스트] <---- Conforms to ----> [Upstream 컨텍스트]
  

  Anti-Corruption Layer (ACL)
  • 두 컨텍스트 간의 모델 불일치 문제를 해결하기 위해 중간에 변환 계층을 둔다
  • ACL은 외부 모델이 내부 모델에 부정적인 영향을 미치지 않도록 보호한다

  [컨텍스트 A] <---- ACL ----> [컨텍스트 B]
  

• Shared Kernel

 

상황 예제

• 시나리오: 온라인 쇼핑몰 시스템 
  • 온라인 쇼핑몰 시스템에는 여러 바운디드 컨텍스트가 존재할 수 있다
  • 예를 들어, 고객 관리, 주문 처리, 결제, 배송 등이 있다

  [고객 관리] <---- Customer-Supplier ----> [주문 처리] <---- Customer-Supplier ----> [결제]
     \\                                                         /
      \\                                                       /
       \\                                                     /
        \\                                                   /
         \\                                                 /
          \\-----------------------------------------------/
                           Shared Kernel
                          (공통 모델: 주문 정보)
  
  

  1. 고객 관리 (Customer Management)
     1. 고객 정보를 관리하는 컨텍스트
  2. 주문 처리 (Order Processing)
     1. 주문을 관리하고 처리하는 컨텍스트
     2. 이 컨텍스트는 고객 관리 컨텍스트에서 고객 정보를 가져와 사용
  3. 결제 (Payment)
     1. 결제를 처리하는 컨텍스트
     2. 주문 처리 컨텍스트에서 주문 정보를 받아 결제를 진행
  4. 배송 (Shipping)
     1. 주문이 완료된 후 배송을 관리하는 컨텍스트
     2. 주문 처리 컨텍스트와 공통 모델(주문 정보)을 공유
  각 관계 설명
  • Customer-Supplier 관계
    • 고객 관리 컨텍스트와 주문 처리 컨텍스트 간에는 Customer-Supplier 관계
    • 주문 처리 컨텍스트는 고객 관리 컨텍스트의 고객 정보를 필요로 하므로, 고객 관리 컨텍스트가 Supplier 역할을 한다
    • 주문 처리 컨텍스트와 결제 컨텍스트 간에도 Customer-Supplier 관계가 있다
    • 결제 컨텍스트는 주문 정보를 필요로 하므로, 주문 처리 컨텍스트가 Supplier 역할을 한다
  • Shared Kernel
    • 주문 처리 컨텍스트와 배송 컨텍스트는 주문 정보를 공통으로 사용한다
    • 이 경우, 주문 정보 모델을 Shared Kernel로 공유하여 두 컨텍스트 간의 일관성을 유지한다

 

모델 탐색 (Model Exploration)

• 정의
  • 모델 탐색은 도메인 전문가와 개발자가 협력하여 도메인 모델을 점진적으로 개발하고 개선하는 과정
• 중요성
  • 초기 모델은 불완전하거나 잘못될 수 있다
  • 모델 탐색을 통해 지속적으로 도메인 지식을 반영하고, 모델을 개선함으로써 더 나은 도메인 이해와 시스템 설계를 이룰 수 있다

지속적인 학습 (Continuous Learning)

• 정의
  • 도메인 지식은 고정된 것이 아니라 지속적으로 발전한다
  • 팀은 도메인에 대해 끊임없이 배우고, 이를 모델에 반영해야 한다
• 중요성
  • 지속적인 학습을 통해 도메인 전문가와 개발자 간의 이해가 깊어지고, 도메인 모델이 더욱 정교해진다
  • 이는 시스템의 적응성과 유연성을 높인다

정책 및 규칙 (Policies and Rules)

• 정의
  • 도메인 모델에는 비즈니스 규칙과 정책이 포함되어야 하며, 이는 명확하게 정의되고 공유된 언어로 표현되어야 한다
• 중요성
  • 명확한 정책과 규칙은 모델의 일관성을 유지하고, 시스템이 도메인 요구사항을 정확히 반영하도록 한다

팀 내의 협업 (Collaboration)

• 정의
  • 도메인 전문가와 개발자가 함께 모델링 세션을 갖고, 도메인에 대한 이해를 공유하는 협업 프로세스
• 중요성
  • 협업을 통해 도메인 전문가의 지식을 시스템에 반영할 수 있고, 개발자는 도메인 요구사항을 더 잘 이해하게 된다
  • 이는 더 나은 시스템 설계와 구현으로 이어진다