Chapter2. 바운디드 컨텍스트 및 보편언어와 전략적 설계

[도메인 주도 설계 핵심 - http://www.yes24.com/Product/Goods/48577718]

 

• DDD는 주로 명확하게 바운디드 컨텍스트 내에서 보편언어를 모델링하는 것에 대한 것이다
  • 바운디드 컨텍스트는 의미적으로 동일한 컨텍스트의 범위를 표현
    • 소프트웨어 모델의 각 컴포넌트는 특정한 의미를 갖고 특정한 일을 수행한다
    • 바운디드 컨텍스트 내에 존재하는 컴포넌트들은 컨텍스트에 특화돼 있으며, 컨텍스트 안에서 의미가 살아난다
    • 모델링 작업을 시작하는 시점에서 바운디드 컨텍스트는 개념적인 수준이라 문제 영역의 일부라고 생각할 수도 있지만
      모델이 더 깊은 의미와 명확성을 받아들이게 되면서 빠르게 해결 영역으로 전환된다
      • 문제 영역(problem space) : 상위 수준의 전략적 분석을 수행하고 주어진 프로젝트 제약사항 내에서 단계를 설계하는 곳
      • 해결 영역(solution space) : 문제 영역의 논의가 핵심 도메인으로 바라보는 해결 방안을 구현하는 곳
    • 바운디드 컨텍스트는 모델이 구현되는 곳이고, 바운디드 컨텍스트마다 각각 분리된 소프트웨어 산출물이 나온다
  • 바운디드 컨텍스트 안에서 일하는 팀 구성원들이 이야기할 때 사용되고 소프트웨어 모델 안에 구현할 때 사용하는 언어를 보편 언어라고 한다
    • 보편언어는 엄격하고, 정확하고, 엄중하며, 단호해야 한다
    • 팀의 누군가가 보편언어 표현을 사용하면 팀 모두가 그 표현이 가진 제약사항과 정확한 의미를 이해한다
    • 바운디드 컨텍스트는 마치 언어의 경계와 비슷하다
      • DDD의 경우 보편적 언어라는 것은 소프트웨어 모델을 소유하는 팀이 이야기할 때 사용하는 것이고
        이 언어의 대표적인 기록 형태는 소프트웨어 모델의 소스 코드다
  • 바운디드 컨텍스트가 조직의 핵심 전략적 계획으로 개발되고 있을 때 이를 핵심 도메인이라고 한다
    • 핵심 도메인은 가치 있는 것들을 달성하는 수단이 되기 때문에 가장 중요한 소프트웨어 모델 중 하나이다
    • 기업의 올바른 전략적 결정을 위해 무엇이 핵심 도메인이어야 하고 어떤 것을 제외시켜야 하는지 현명하게 선택해야 한다

 

• 바운디드 컨텍스트, 팀 그리고 소스 코드 리파지토리
  • 각각의 바운디드 컨텍스트는 단일 팀에만 할당돼야 하고
    각 바운디드 컨텍스트마다 독립적인 소스 코드 리파지토리가 있어야 한다
  • 한 팀은 다수의 바운디드 컨텍스트에 대해 일을 할 수 있지만
    다수의 팀이 하나의 바운디드 컨텍스트를 수행할 수는 없다
  • 바운디드 컨텍스트마다 소스 코드와 데이터베이스 스키마도 명확히 분리한다
  • 각 팀은 각자의 소스 코드와 데이터베이스를 소유하고 공식 인터페이스를 정의해서 바운디드 컨텍스트를 다른 팀이 사용할 수 있게 허용한다

 

도메인 전문가와 비즈니스 동인

• DDD는 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 안으로 분리해 높음으로써 개념 간 차이를 중시한다
• 각기 다른 언어와 그에 따른 기능이 존재하는 것을 인정한다

 

기본적인 전략적 설계를 하려면

• DDD의 전략적 설계 도구 - 바운디드 컨텍스트, 보편 언어
• 바운디드 컨텍스트를 사용하는 것은 "핵심이 무엇인가?"라는 질문에 답하도록 유도한다
  • 전략적 계획의 핵심이 되는 모든 개념들을 밀접하게 유지하면서 포용해야 하고 나머지는 모두 제외시켜야 한다
  • 핵심만 걸러낸 후 바운디드 컨텍스트에 남은 개념들은 팀이 사용하는 보편언어의 일부가 된다
    • 경계는 그 안의 엄격함을 강조한다
• 핵심을 알아내는 방법
  • 필수적인 두 가지 그룹(도메인 전문가와 소프트웨어 개발자)을 하나로 묶어 서로 협업하는 팀을 만들어야 한다
  • 도메인 전문가는 비즈니스 문제에 좀 더 집중한다
    • 그들은 비즈니스가 동작하는 방법에 대한 비전에 의미를 둔다
    • 다양한 비즈니스 영역들마다 존재한다
    • 팀의 보편 언어의 토대는 비즈니스를 바탕으로 한 도메인 전문가들의 멘탈 모델이다
  • 소프트웨어 개발자는 개발에 중점을 둔다
    • DDD 프로젝트를 수행하는 개발자는 핵심 전략 목표의 비즈니스 초점을 받아들이지 못하는 기술 중심의 주장을 하지 않도록 조심해야 한다
    • 개발자는 근거 없는 간결성은 피하고 해당 팀의 바운디드 컨텍스트 안에 팀이 점진적으로 개발하는 보편언어를 수용할 수 있어야 한다
    • 기술적 복잡도가 아닌 비즈니스 복잡도에 집중해야 한다
  • 개발자와 도메인 전문가 모두 문서가 대화를 지배하는 상황을 피해야 한다
    • 최고의 보편언어는 서로 협업하며 나오는 거듭된 피드백에 의해 만들어지며 이 과정에서 팀의 화합된 멘탈 모델을 만들 수 있다
    • 열려 있는 대화, 탐구 그리고 현재의 지식 기반에 대한 도전의 결과는 핵심 도메인에 대한 더 깊은 통찰로 이어질 것이다

 

도전과 통합

• 거대한 모델의 각 개념들이 스크럼의 보편언어를 따르는지 되묻는다
• 개념들이 바운디드 컨텍스트 내에 있는지 확인한다
• 모델 관련 여러 가지 시도를 통해 좀 더 깔끔하고 명확한 보편 언어 모델이 만들어진다
• 협업 컨텍스트 : 다른 바운디드 컨텍스트와의 협업을 통해 적절하게 동작한다
• 여러 단계들을 거쳐 실제 핵심 도메인만 남는다
  • 핵심 도메인은 스크럼의 보편언어에 따르는 새로운 개념들로만 확장될 것이다
• 핵심 도메인에서 제외시켰던 다른 모델링 개념들은 각각의 바운디드 컨텍스트 내에 정의될 가능성이 높고 각각의 보편언어에 연결될 것이다
  • 컨텍스트 매핑으로 통합

 

보편언어 개발하기

• 개발자들은 도메인 모델 안의 명사에 너무 많은 의미를 부여하는 경향이 있다
• 핵심 도메인을 명사에만 제한시킬 필요가 없다
• 핵심 도메인이 도메인 모델에 나타난 개념에 대한 구체적인 시나리오들을 나타낼 수 있게 만들어야 한다
•  시나리오
  • 소프트웨어 프로젝트에서 흔히 말하는 use case나 user story 같은 것을 의미하지 않는다
  • 어떻게 도메인 모델이 동작해야 하고 어떤 다양한 컴포넌트들이 동작하는지에 대한 시나리오를 뜻한다
  • 매우 실제적인 소프트웨어 모델 컴포넌트들이 스크럼 기반 프로젝트 관리를 지원하기 위해 어떻게 동작할 것인지를 나타내는 세부사항이다
  • 실제로 도메인 모델이 어떻게 동작하는지 그리고 그 설계에 대해 대화할 수 있다는 것이 가장 중요한 이점이자 도움이 되는 특징이다
  • 시나리오 안의 개념에 이름을 붙이거나 구별할 수 있는 정체성을 부여하는 것이 도움이 될 때만 별도의 이름과 구분짓는 특성을 부여하자
• 작업에 시나리오 넣기
  • 사례를 통한 명세 - 행위 주도 개발(BDD: Behavior-Driven Development)
    • 목적 : 공유된 이해를 기반으로 보편언어와 모델을 협업을 통해 개발 및 정제하고, 모델이 명세서를 준수하고 있는지를 확인하는 것
  • given/when/then 등의 표현을 사용해 작성한 시나리오는 검증에 용이하다
  • 도메인 모델을 검증할 때 인수 테스트(단위 테스트가 아님)를 생성해 검증할 수도 있지만 단위 테스트 프레임워크를 사용해서 이와 거의 비슷한 결과를 달성할 수도 있다
    • 인수 테스트에 대한 단위 테스트 기반 점근법은 실행 가능한 명세와 동일한 목적을 달성시켜준다
  • 접근법들은 모두 일반적으로 녹-적(성공-실패) 방식에 사용할 수 있는데 처음 수행할 때의 명세는 실패다
    • 일련의 적색(실패) 결과들을 기반으로 완전히 명세를 구현하고 검증을 통과(모두 녹색 결과를 확인)하게 될 때까지 도메인 모델을 단계적으로 정제해 나간다
    • 인수 테스트는 직접적으로 바운디드 컨텍스트와 연관되고 소스 코드 리파지토리에 유지된다
• 많은 시간과 노력이 드는 일은?
  • 초기에 개발됐던 보편언어는 해가 지나도 계속해서 성장해야 한다
  • 오랜 기간 지속적인 노력을 이끌어낼 수 없다면, 이 모델이 과연 지금 이 순간 정말로 전념해야 하는 전략적 차별화 요소, 즉 "핵심도메인인가?"라고 반문해봐야 할 것이다

 

아키텍처

• 바운디드 컨텍스트는 도메인 모델 이상의 다양한 요소들로 구성되어 있다
  • 사용자 인터페이스 컨트롤러
  • REST endpoints
  • message listeners
  • input adapter
  • application services
  • 도메인 모델
  • persistence management
  • message senders
  • output adapters
  • ...
• 도메인 모델은 기술로부터 최대한 자유로워야 한다
• 여러 아키텍처들을 조합해서 사용할 수 있다
  • 이벤트 주도 아키텍처
  • 커맨드-쿼리 책임 분리(CQRS: Command Query Resposibility Segregation)
  • 반응 및 액터 모델
  • REST(Representational State Transfer)
  • 서비스 지향 아키텍처(SOA)
  • 마이크로서비스
  • 클라우드 컴퓨팅
  • ...

 

요약

• 너무 많은 것을 하나의 모델에 넣는 것과 큰 진흙 덩어리를 만드는 것과 관련된 몇 가지 중요한 위험 요소들
• DDD 전략적 설계의 적용
• 바운디드 컨텍스트와 보편언어의 사용
• 가정들에 대한 분석과 멘탈 모델을 통합하는 방법
• 보편언어를 개발하는 방법
• 바운디드 컨텍스트 내에서 발견할 수 있는 아키텍처 컴포넌트
• 스스로 DDD를 실행 방안에 넣는 것이 전혀 어려운 일이 아니라는 것