- 프로젝트 성공을 위해서는 모든 이해관계가 의사소통에서 사용할 수 유비쿼터스 언어가 중요
- 명확하고 일관성 있어야함
- 모호성, 암묵적인 가정, 관련없는 세부 사항이 없어야함
- 그러나 도메인 전문가 멘탈 모델은 일관성이 없을 수 있음
- 같은 비즈니스 도메인에서도 도메인 전문가마다 다른 모델을 사용할 수 있음
일관성 없는 모델
- 텔레마케팅 회사의 예시
- 부서(컨텍트스)마다 리드(lead)라는 용어가 다른의미로 사용됨
- 마케팅 부서
- 온라인 광고를 통해 리드(lead)를 생성
- 누군가 제품 중 하나에 관심이 있다는 알림, 잠재고객의 연락처를 수신하는 이벤트
- 영업 부서
- 영업 프로세스의 전체 수명 수기를 의미 (훨씬 복잡함)
- 단순 이벤트가 아니라 장기적으로 진행되는 과정
- 단순한 의사소통에서는 문제가 되지 않음
- 개인 대 개인
- 다른 부서 사람들과의 의사소통 -> 어려울수 있지만 가능
- 문제는 다양한 도메인을 소프트웨어로 표현하는것이 어려움
- 소스코드는 모호성을 잘 대처하지 못함
- 영업 관점을 마케팅에 적용 (오버 엔지니어링)
- 마케팅 관점에 따라 영업 모델을 단순화 -> 언더 엔지니어링
- 이러한 문제를 해결하기 위한 전통적인 방법은 단일 모델을 설계하는것 -> 하나의 거대한 ERD?
- 모든것에 적합하지만 결국 아무 소용이 없다
- 결국 복잡성에 직면하게 됨
- 관련없는 세부 사항 필터링
- 필요한것을 선별
- 데이터를 일관된 상태로 유지
- 다른 해결 방법으로 ‘마케팅 리드’와 ‘영업 리드’와 같이 접두사를 추가하는것
- 두 모델을 코드로 표현가능
- 두 가지 주요 단점이 존재
- 충돌하는 모델을 계속 구현할수록 -> 인지부하
- 모델의 구현이 유비쿼터스 언어와 일치하지 않음 -> 대화할때는 접두사를 사용하지 않음
바운디드 컨텍스트
- 위와 같은 문제를 다루는 도메인 주도 설계 패턴
- 유비쿼터스 언어를 여러 개의 작은 언어로 나눔
- 각 언어를 적용할 수 있는 명시적인 바운디드 컨텍스트에 할당
- 위 예에서는 두개의 컨텍스트로 구분해서 유비쿼터스 언어 설계
모델 경계, 유비쿼터스 언어
- 모델은 복잡한 시스템을 이해하기 위해 구조화한 것
- 우리가 해결하려는 문제는 모델 본연의 목적
- 경계없이 존재할 수 없음
- 지도 예시
- 항공, 해상, 지형, 지하철 등 특정 컨텍스트가 존재
- 특정 목적 내에서만 유용하고 일관성을 유지할 수 있음
- 해결하려는 문제 도메인에 따라 (바운디드 컨텍스트 내에서)고유한 모델(유비쿼터스 언어)을 정의할 수 있음
- 지하철 노선 -> 자동차 운행에 쓸모가 없음
- 바운디드 컨텍스트의 유비쿼터스 언어는 다른 바운디드 컨텍스트 범위에서는 완전히 관련없음
- 유비쿼터스 언어는 바운디드 컨텍스트에 포함된 모델들을 설명하는데만 집중
바운디드 컨텍스트 범위
- 바운디드 컨텍스트(유비쿼터스 언어의 범위)를 정의함으로써 서로 다른 도메인 전문가들이 동일한 비즈니스 엔티티에 대해 가지는 상충되는 멘탈 모델을 구분할 수 있었음
- 경계는 비즈니스 도메인의 컨텍스트에 따라 넓히거나 줄일 수 있음
- 컨텍스트 크기 자체는 의사결정 요소가 아님 -> 정답이 없는 문제
- 다만 모델 자체로 유용해야함
- 경계가 넓을수록 일관성 유지가 어려움
- 작계만들수록 설계를 통합하는 오버헤드가 커짐
- 큰 바운디드 컨텍스트에서 세분화된 컨텍스트를 추출
- 새로운 엔지니어링 팀 구성(독립적 확장), 컨텍스트의 일부 컴포넌트 개발 생명주기 분리등
- 바운디드 컨텍스트의 크기는 비즈니스 요구사항과 조직의 제약사항에 맞춰야함
- 응집된 기능을 여러 바운디드 컨텍스트로 분할시 고려해야할 비효율성
- 컨텍스트가 독립적으로 발전하는 능력을 저해함
- 같은 비즈니스 요구사항이 여러 바운디드 컨텍스트에 영향을 미침
바운디드 컨텍스트 vs 하위 도메인
- 기업의 비즈니스 전략을 이해하기 위해서는 비즈니스 도메인 분석(다양한 하위 도메인 식별) 필요
- 요구사항 -> 유스케이스 (하위 도메인)
- 비즈니스 담당
- 바운디드 컨텍스트는 소프트웨어 엔지니어에 의해 설계됨
- 소규모 시스템에서는 단일 모델이 효과적일 수 있음
- 모델이 충돌하면 바운디드 컨텍스트로 분해할 수 있음
- 중요한 것은 하위 도메인은 발견(하위 도메인은 비즈니스 전략에 의해 정의), 바운디드 컨텍스트는 설계한다는 점
경계
- 바운디드 컨텍스트 패턴은 물리적 경계와 소유권 경계를 규정하기 위한 도구
- 물리적 경계
- 시스템의 물리적 경계
- 서비스, 프로젝트 (구현, 진화, 버전) 등
- 소유권 경계
- 바운디드 컨텍스트는 한 팀에서만 구현, 관리 해야함
- 팀간 서로 독립성을 잘 지켜야함 → 두 팀이 같은 바운디드 컨텍스트에서 작업할 수 없음
- 서로 분리된 모델을 사용하고 시스템 연동을 위한 통신 프로토콜을 정의
실생황의 바운디드 컨텍스트
- 바운디드 컨텍스트는 비즈니스 도메인, 하위 도메인만큼 분명하지는 않음
- 그러나 도메인 전문가 멘탈 모델이 있는것 처럼 존재함
- 소프트웨어 엔지니어는 도메인 전문가가 다양한 비즈니스 엔티티와 프로세스에 대해 어떻게 생각하는지 의식해야함
- 시맨틱 도메인
- 두가지 영역으로 구분
- 의미 영역
- 해당 의미를 전달하기 위해 사용하는 단어 영역
- 소프트웨어와 하드웨어에서 다음 단어들의 의미가 다름
결론
- 하위 도메인이 발견되면 바운디드 컨텍스트도 설계
- 바운디드 컨텍스트와 유비쿼터스 언어는 한 팀에서 만들고 유지보수 가능
- 두 팀이 동일한 바운디드 컨텍스트에서 작업 공유 X