전술패턴을 이해하고 실행하려다 보면 도메인/서브도메인, 핵심/보조, 서브도메인/바운디드컨텍스트 여러가지 정의하지 못했던 요소들에 대해서 딱 이거다 하고 정의하기 어려웠다.
비슷한 고민을 하고 정리한 글을 봤다.
https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c
결론부터 말하자면 다 봐도 여전히 정의하기 어렵긴 하다.
하지만 왜 정의하기 어려운지를 알수 있었고 여러 의견들을 수용할수 있을것 같다.
1. 도메인은 주관적이며 상호 배타적이지 않다.
2. 도메인과 서브도메인은 상대적 인것이다.
그 크기나 위치가 중요한게 아니다. 다른 상위 도메인의 자식임을 강조하고싶을때만 서브라는 표현을 쓰면 된다
3. 서브도메인과 바운디드컨텍스트
- 서브도메인 : 문제영역
- 바운디드컨텍스트 : 해결영역
이 구분도 20년전 DDD 가 발행되었을 시점을 생각했을때 IT 팀이 별도로 있었을때나 의미가 있고 현재로써 그 구분은 무의미하다고 한다.
하지만 반버논 책에서는 "바운디드컨텍스트와 서브도메인은 1:1이 이상적이다" 라고 표현 하는걸 보면 어쨌든 불일치가 있는 상황도 있을것이다.
한번쯤 구분하여 고민 하는것에도 좋을것 같다.
4. 문제영역 해결영역
두 공간에 어떤게 존재해야하는지는 다들 관점이 다르다.
차라리 문제를 인지하고 해결하는 과정을 사이클로 관리하는 방법에 대한 고민을 하는게 유용하다.
Wardley의 전략 주기의 요소들.
- Purpose (목적) : 우리의 관심 영역에서 해결되고 있는 문제/달성 목표는 무엇입니까?
- Landscape (풍경) : 관심 있는 도메인의 현재 상태입니다.
- Climate (기후) : 영역에 어떤 힘이 작용하고 있으며 어떻게 진화할 것 같은지
- Climate (교리) : 우리가 적용해야 하는 보편적인 모범 사례
- Leardership (리더십) : 우리의 솔루션은 무엇입니까… 기존 및 새 도메인에서 어떤 변경 사항을 만들 것입니까?
5. 도메인/서브도메인은 문제영역? 해결영역?
책을 집에 두고와서 기차에서 못읽는 상황을 책회사에서는 어떻게 문제를 인지하고 해결하려고 할까?
Reading 이라는 도메인 안에서 문제영역을 책 서브도메인 으로 구분했고 해결영역을 ebook 서브도메인 으로 구분했다.
ebook 이라는 프로덕트 안에서 사실상 book 이라는 코드는 찾을수 없을지도 모르나 엄연히 존재하는 영역이다.
게다가 Reminders 라는 해결영역이 하나 더 있다.
문제영역 1개에 해결영역 2개가 될수있다.
만약 코드만 보고서 도메인을 파악하려 한다면 무엇이 문제인지 놓칠수 있다.
대부분 해결의 결과물만 있을 테니까.
그리고 어떤 해결영역 도메인은 누군가에게 문제영역이 될수도 있다.
그림에서는 ebook 을 클라우드 스토리지라는 범용도메인을 사용 했으나, 이것의 사용성을 늘릴 클라우드회사에서는 문제영역이기도 하다.
이렇게 문제를 식별하고 해결하는 과정은 반복 되어야 한다.
예를들어 배달회사에서 배달 시스템이 큰문제가 없고 현재로써 완벽하다면 다른 문제영역을 찾아보는게 낫다.
때문에 Wardley의 전략주기는 현실적인 조언이 아닐까 싶다.
6. 서브도메인과 vs 바운디드컨텍스트
- 바운디드컨텍스트는 모델의 경계이므로 여러 서브도메인의 개념을 포함할 수 있다.
- 또는 단일 서브도메인을 여러개의 바운디드컨텍스트로 모델링 할수도 있다.
