도메인 주도 설계 핵심
1장 나에게 도메인 주도설계는
설계가 필수적인 것인지, 안해도 괜찮은지에 대한 질문은 요점에서
많이 벗어나 있다. 설계는 필연적이다. 좋은 설계의 대은은 나쁜 설
계다. 절대 설계하지 않는 것이 아니다. - 더글라스 마
전략적 설계가 두꺼운 붓 터치라면, 전술적 설계는 얇은 붓을 사용하는 것과 같다.
2장 바운디드 컨텍스트 및 보편언어와 전략적 설계
DDD 는 주로 명확하게 바운디드 컨텍스트 내에서 보편언어를 모델링하는 것에 대한 것이다. 바운디드 컨텍스트는 의미적으로 동일한 컨텍스트의 범위를 표현한다. 바운디드 컨텍스트 내에 존재하는 컴포넌트들은 컨텍스트에 특화돼 있으며, 컨텍스트 안에서 의미가 살아난다. 소프트웨어 모델링 작업을 막 시작하려고 할때, 이것을 문제영역(problem space)의 일부라고 생각할 수도 있지만, 모델이 더 깊은 의미와 명확성을 받아들이게 되면서 빠르게 해결영역(solution space)로 전환되고, 소프트웨어 모델은 프로젝트 소스 코드로 반영되기 시작할 것이다. 바운디드 컨텍스트는 모델이 구현되는 곳이고, 바운디드 컨텍스트 마다 각각 분리된 소프트웨어 산출물이 나온다.
문제 영역과 해결 영역은 무엇인가?
문제 영역은 상위 수준의 전략적 분석을 수행하고, 주어진 프로젝트 제약사
항 내에서 단계를 설계하는 곳이다. 상위 수준의 프로젝트 요인에 대해 논의
하고, 주요 목표와 위험 사항에 대해 이야기하면서 간단한 다이어그램을 사
용할 수도 있다. 실제로 컨텍스트 맵은 문제영역에서 매우 잘 활용된다. 바
운디드 컨텍스트는 문제영역 논의에서 사용할 수 있지만, 필요에 따라 해결
영역과도 밀접하게 관련된다는 것을 잘 기억해두자
해결영역은 문제 영역의 논의가 핵심 도메인으로 바로보는 해결방안을 구
현하는 곳이다. 바운디드 컨텍스트를 조직의 핵심 전략 계획으로 개발하고
있을 때, 이를 핵심 도메인이라고 한다. 바운디드 컨텍스트 내에서 메인소스,
테스트 소스 코드로 해결방안을 개발한다. 다른 바운디드 컨텍스트와의 통
합을 지원하는 해결 영역에서도 코드를 생산한다.
팀 구성원들이 이야기할 때 사용되고, 소프트웨어 모델 안에 구현되기 때문에 보편언어 라고 부른다. 보편언어는 엄격하고, 정확하고, 엄중하며, 단호해야 한다. 바운디드 컨덱스트가 조직의 핵심 전략적으로 개발되고 있을 때, 이를 핵심도메인 이라고 한다. 핵심도메인은 다른 조직과의 경쟁에 대한 차별화를 위해 개발한다. 기업의 올바른 전략적 결정을 위해 무엇이 핵심 도메인이어야하고, 어떤 것을 제외시켜야하는지 현병하게 선택해야한다. 이것이 DDD의 주된 가치 제안이고, 핵심도메인에 최적의 자원을 투여해서 적절하게 투여해야 한다. 바운디드 컨택스트는 마치 언어의 경계와 비슷하다. DD의 경우, 보편적 언어라는 것은 소프트웨어 모델을 소유하는 팀이 이야기할 때 사용하는 것이고, 이 언어의 대표적인 기록 형태를 소프트웨어 모델의 소스코드다.
**바운디드 컨텍스트, 팀, 그리고 소스 코드 리파지토리**
각각의 바운디드 컨텍스트는 단일 팀에만 할당 돼야하고, 각 바운디드 컨텍
스트 마다 독립적인 소스 코드 리파지토리가 있어야 한다. 한 팀은 다수의 바
운디드 컨텍스트에 대해 일을 할 수 있지만,다수의 팀이 하나의 바운디드
컨텍스트를 수행할 수는 없다. 보편언어를 나눈것과 같은 방법으로 바운디
드 컨텍스트마다 소스코드와 데이터베이스 스키마도 명확히 분리한다. 메인
소스 코드와 함 께 인수 테스트와 단위 테스트를 유지해야 한다.
각 팀은 가가자의 소스코드와 데이터베이스를 소유하고, 공식 인터페이스를
정의해서 바운디드 컨텍스트를 다른 팀이 사용할 수 있게 허용한다. 이것이
DDD 사용의 이점이다.
큰 진흙 덩어리는 이런 비지니스 전문자의 이야기에 귀를 기울이지 않은 채, 소프트웨어 개발팀이 제멋대로 노력한 결과다.
#