DDD는 바운디드 컨텍스트 내에서 보편언어를 모델링하는 것에 대한 것이다.
바운디드 컨텍스트
- 바운디드 컨텍스트는 의미적으로 동일한 컨텍스트 범위를 표현한다.
- 바운디드 컨텍스트가 조직의 핵심 전략적 계획으로 개발되고 있을 때, 이를 핵심 도메인이라고 한다.
- 테스트를 하나의 모델에 집중이 가능하다는 이점이 있다.
- 엄격하게 핵심만 걸러낸 후 살아남은 개념들은 해당 바운디드 컨텍스트를 소유하는 팀의 보편언어 일부가 된다. 경계는 그 안의 엄격함을 강조한다.
보편언어
- 보편언어는 팀 구성원들이 이야기할 때 사용되고, 소프트웨어 모델 안에 구현되는 언어이다.
- 엄격하고 정확하고 엄중하며 단호해야 한다.
- 상자는 클래스를 의미
- 너무 많은 것을 하나의 모델에 넣는 것은 큰 진흙 덩어리를 생산하는 것이다.
- 이는 보편언어를 개발하고 사용하려는 모든 시도가 갈라지고, 불분명해져, 곧 버려질 모델을 만들어낼 뿐이다.
- DDD는 서로 다른 개념들을 각기 다른 바운디드 컨텍스트 안으로 분리해 놓음으로써 개념 간 차이를 더욱 중시한다.
한 묶음 = 도메인 전문가 + SW 개발자
- 도메인 전문가와 SW 개발자는 한 묶음이다.
- 도메인 전문가는 비즈니스 문제에 좀 더 집중한다.
- SW 개발자는 개발에 중점을 두지만 너무 기술에만 빠져 있으면 안된다.
- 기술 복잡도가 아닌 비즈니스 복잡도에 집중할 것
핵심 도메인이 아닌 다른 모델링 개념 처리는?
- 각각의 바운디드 컨텍스트 내에 정의 -> 보편언어에 연결 -> 필요에 따라 컨텍스트 매핑(통합)
핵심 도메인
- 핵심 도메인은 도메인 모델에 나타난 개념에 대한 구체적인 시나리오들을 나타낼 수 있게 만들어야 한다.
- 핵심 도메인에 대한 정의가 꼭 명사가 아니어도 됨
- 핵심 도메인에 유지 단계 라는 딱지를 붙이는 것은 최악이다.
- 계속해서 핵심 도메인에 대한 보편언어를 성장시켜야 한다.
- 지속적인 노력을 이끌어 낼 수 없다면? 핵심 도메인이 될 수 있는가? 에 대해 고민해봐야 한다.
기타
- 다른 아키텍처나 아키텍처 패턴도 목적에 따라 조합해서 사용할 수 있다.
- DDD를 실행해보는 것은 어려운 일이 아니다.
손으로 정리
백엔드 개발자