2.바운디드 컨텍스트 및 보편언어와 전략적 설계
바운디드 컨텍스트
- 의미적으로 동일 컨텍스트의 범위를 표현.
- 모델이 구현되는 곳이고, 각각 분리된 소프트웨어 산출물이 나옴.
- 각각의 바운디드 컨텍스트는 단일 팀에만 할당되어야 하고, 독립적인 소스 코드 레포지토리가 있어야 함.
- 하나의 팀이 여러 바운디드 컨텍스트를 수행할 수는 있으나, 여러 팀이 하나의 바운디드 컨텍스트를 수행할 수는 없음.
- 바운디드 컨텍스트마다 소스 코드와 데이터베이스 스키마를 명확하게 분리해야 함.
- 각 팀은 각자의 소스 코드와 데이터베이스를 소유하고, 공식 인터페이스를 정의해서 바인디드 컨텍스트를 다른 팀이 사용할 수 있게 허용.
핵심 도메인
- 조직 핵심 전략적 계획으로 개발되고 있는 가장 중요한 바운디드 컨텍스트.
보편 언어
- 바운디드 컨텍스트 안의 소프트웨어 모델을 만드는 모든 팀 구성원이 사용하는 공통 언어.
- 팀원 모두가 보편 언어의 표현에 대한 제약사항과 정확한 의미를 이해해야 함.
- 보편 언어의 대표적인 기록 형태는 소프트웨어 모델의 소스 코드.
큰 진흙 덩어리
- 시스템의 명확한 경계 없이 여러 개의 뒤엉킨 모델들을 담고 있는 것.
- 비즈니스 전문가의 이야기에 귀를 기울이지 않은 채, 소프트웨어 개발 팀이 제멋대로 노력한 결과.
정책
- 비즈니스 형태에 따라 정책(Policy)이라는 개념의 의미는 제각각 달라짐.
- 사업 부서는 세 곳인데 서 가지 정책 모두를 하나의 정책으로 통합하려고 한다면, 분명 문제가 발생.
- DDD는 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 안으로 분리해 놓음으로써 개념 간 차이를 중시.
- 각 정책들의 이름은 3개의 모든 바운디드 컨텍스트 내에서 단순히 정책으로 표현.
문제 영역과 해결 영역
문제 영역 - 상위 수준의 전략적 분석을 수행하고, 주어진 프로젝트 제약사항 내에서 단계를 설계하는 곳.
해결 영역 - 문제 영역의 논의가 핵심 도메인으로 바라보는 해결 방안을 구현하는 곳.
기본적인 전략적 설계를 하려면
- 2개의 기본적인 전략적 설계 도구
- 바운디드 컨텍스트
- 보편언어
- 바운디드 컨텍스트는 전략적 계획의 핵심이 되는 모든 개념들을 밀접하게 유지하면서 포용해야 하고, 나머지는 모두 제외시켜야 함.
- 바운디드 컨텍스트에 남은 개념들은 팀이 사용하는 보편언어의 일부가 됨.
- 핵심을 파악하기 위해서는 도메인 전문가와 소프트웨어 개발자가 협업하는 팀을 구성해야 함.
- 도메인 전문가: 비즈니스 문제에 집중. 팀의 보편 언어의 토대는 도메인 전문가들의 멘탈 모델.
- 소프트웨어 개발자: 소프트웨어 개발에 중점. 비즈니스 초점을 받아들이지 못하는 기술 중심의 주장을 하지 않도록 주의.
도전과 통합
- 가장 간단한 도전은 거대한 모델의 각 개념들이 스크럼의 보편언어를 따르는지 되묻는 것.
- 스크럼과 아무런 관련이 없을 경우, 스크럼 소프트웨어 모델에서 제외.
- 스크럼과 관련이 있을 경우, 스크럼의 보편언어에 맞춰 통합.
- 핵심 스크럼 언어의 일부가 아닌 경우, 컨텍스트 모델에서 제외.
- 협업 컨텍스트: 바운디드 컨텍스트와 협업하는 또 다른 바운디드 컨텍스트.
- 제외되었던 다른 모델링 개념들은 각각의 바운디드 컨텍스트 내에 재정의. 이후 컨텍스트 매핑을 통해 통합.
보편언어 개발하기
- 핵심 도메인을 명사에만 제한시킬 필요가 없다.
- 그보다는 핵심 도메인이 도메인 모델에 나타난 개념에 대한 구체적인 시나리오를 나타낼 수 있게 만들어야 한다.
- 시나리오는 단지 사람이 수행한 절차에 대해 이야기하는 것이 아닌, 매우 실제적인 소프트웨어 모델 컴포넌트들이 스크럼 기반 프로젝트 관리를 지원하기 위해 어떻게 동작할 것인지를 나타내는 세부사항이다.
- 문서 자체는 도메인 모델이 아닌, 도메인 모델 개발을 도와주는 도구일 뿐이다. 결국엔 코드가 모델이고, 모델이 코드다.
- 시나리오 안의 개념에 이름을 붙이거나 구별할 수 있는 정체성을 부여하는 것이 도움이 될 때만, 별도의 이름과 구분짓는 특성을 부여하자.
- 현재의 모델에 질문을 던짐으로서 좀 더 심도 깊은 통창을 얻을 수 있는 기회를 가지게 된다. 이러한 질문과 고민은 모델링 통찰로 이어진다.
작업에 시나리오 넣기
- 행위 주도 개발(BDD): 사례를 통한 명세
- 공유된 이해를 기반으로 보편언어와 모델을 협업을 통해 개발 및 정제하고, 모델이 명세서를 준수하고 있는지 확인하는 목적.
- given, when, then
- 녹-적(성공-실패) 방식
- 처음 수행할 때의 명세는 실패.
- 일련의 적색(실패) 결과들을 기반으로 완전히 명세를 구현하고 검증을 통과(모두 녹색 결과를 확인)하게 될 때까지 도메인 모델을 단계적으로 정제해 나감.
많은 시간과 노력이 드는 일은?
- 팀의 유지가 시작될 때, 혁신은 끝났다고 생각하는 것은 큰 착각.
- 초기에 개발됐던 보편언어는 계속해서 성장해야 함.
- 오랜 기간 지속적인 노력을 이끌어낼 수 없다면, 핵심 도메인인가? 라고 반문.
아키텍처
- 바운디드 컨텍스트는 도메인 모델 이상의 다양한 요소들로 구성됨.
- 이벤트 주도 아키텍처: 이벤트 소싱
- 커맨트-쿼리 책임 분리(CQRS)
- 반응 및 액터 모델
- REST: Representational State Transfer
- 서비스 지향 아키텍처(SOA)
- 마이크로서비스
- 도메인 모델은 기술로부터 최대한 자유로워야 함.
- 바운디드 컨텍스트와 마이크로서비스는 같은 스크럼 기반 컨텍스트와 의미의 범주 내에 있음.(바운디트 컨텍스트 == 마이크로서비스)
요약
- 너무 많은 것을 하나의 모델에 넣는 것과 큰 진흙 덩어리를 만드는 것과 관련된 몇 가지 중요한 위험 요소들
- DDD 전략적 설계의 적용
- 바운디드 컨텍스트와 보편언어의 사용
- 가정들에 대한 분석과 멘탈 모델을 통합하는 방법
- 보편언어를 개발하는 방법
- 바운디드 컨텍스트 내에서 발견할 수 있는 아키텍처 컴포넌트
