도메인 주도 설계 핵심 이라는 책을 기반으로 사내 스터디를 진행 하였다.
프론트 개발자이지만 도메인 서비스를 설계하고 더 좋은 도메인 서비스를 만드는 방법은 흥미로웠고 재미 있었던거 같다.
바운디드 컨텍스트
- 의미적으로 동일한 컨텍스트의 범위를 표현
- 특정 범주 내에서 해당 모델이 특정한 의미를 갖고 특정한 일을 수행한다는 뜻
- 문제영역 + 해결영역
- 문제영역: 주어진 프로젝트의 상위 수준의 전략적 분석을 수행하며 문제를 정의하는 곳
- 해결영역: 문제 영역의 논의가 해결 방안으로 구현하는 곳
- 하나의 바운디드 컨텍스트→ 고유한 정책을 가짐→ 독립적인 모델이 구현됨→ 독립적인 소프트웨어 산출됨
보편언어
- 바운디드 컨텍스트 내에서 소프트웨어를 만드는 팀 구성원이 사용하는 언어
- 엄격하고 정확하고 엄중하고 단호해야함
- 팀의 누군가가 보편언어 표현을 사용하면 팀 모두가 그 표현이 가진 제약사항과 정확한 의미를 이해할 수 있어야함 (컨센선스가 맞춰짐)
49p 항공 산업 내에서도 “비행”의 의미는 여러가지를 갖는다. 비행기가 공항에서 다른 공항으로 가는 한 번의 이륙 착륙으로 정의한 “비행” 또는 정비 관점에서의 “비행” 또는 직항/경유 구분 없이 탑승 발권을 의미하는 “비행”. 이처럼 각각의 컨텍스트 내에서만 “비행”이 갖는 의미를 명확하게 이해할 수 있기 때문에 이들을 분리해 컨텍스트 내에 모델링해야한다. 한 컨텍스트 안에 모델링한다면 뒤엉켜 엉망이 될 것이다.
핵심도메인
- 조직의 핵심 전략적 계획
- 전략적 차별화 요소
경계해야할 것
- 모델 안에 너무 많은 개념이 존재하는 것→ 하나의 거대하고 혼란스럽고 경계가 제한되지 않은 모델이됨 (진흙덩어리..)→ 언어가 혼재되면서 점차 모델 내의 보편언어가 모호해짐
- 보편언어, 핵심 도메인이 “유지단계”로 접어들어 혁신은 끝났다는 착각
전략적 설계
- 전략적 계획의 핵심이 되는 개념들을 밀접하게 유지하면서 포용하며 나머지는 모두 단호하게 제외시켜야 함
- 엄격하게 핵심만 걸러내어 정의한 개념들을 바운디드 컨텍스트를 소유하는 팀이 사용할 보편언어로 포함시킴
컨텍스트 맵핑 – 도메인 모델링 예시
Discussion이란 개념은 핵심 모델 중 일부이며 바운디드 컨텍스트 내에 있지만
Discussion이란 개념만으로는 완전하게 그 의미를 표현하기 어려움
이런 경우 그것을 지원하는 여러 부수적인 컴포넌트들이 필요하게 됨
하지만 이런 보조적인 개념들을 동일 바운디드 컨텍스트에 모델링하는 것이 아니라
별개의 컨텍스트로 분리해야 함
→ 이러한 단계들을 통해 하나의 바운디드 컨텍스트에 핵심 도메인만 남기는 것이 중요
→ 메인 바운디드 컨텍스트와 그 외 컨텍스트 간의 통합은 컨텍스트 맵핑을 통해 이루어짐
보편언어 개발하기
- 너무 명사에 집착할 필요는 없다
- 핵심 도메인이 되는 필수적인 모델 요소들만 보편언어로 만들자
- 실제로 도메인 모델이 어떻게 동작하는지 그리고 그 설계에 대해 대화할 수 있는 수준으로 만드는 것이 가장 중요
문서 자체는 도메인 모델이 아니다. 더 정확히 말하면 도메인 모델 개발을 도와주는 도구일 뿐이다. 결국엔 코드가 모델이고 모델이 코드다.