열린 대화, 탐구, 피드백 -> Ubiquitous Language

 

DDD를 사용하는 이유는 비즈니스 모델의 복잡도가 높기 때문이다. 그렇다고 해서 도메인 모델이 가져야 하는 복잡도 이상으로 더 복잡한 모델을 만들 이유는 없다. 프로젝트의 기술적 측면보다 비즈니스 모델이 더 복잡하기 때문에 DDD를 사용한다. 이것이 바로 개발자가 도메인 전문가와 함께 비즈니스 모델을 파고들어야 하는 이유다 !

개발자와 도메인 전문가 모두 문서가 대화를 지배하는 상황을 피해야한다. 최고의 보편언어는 서로 협업하며 나오는 거듭된 피드백에 의해 만들어지며, 이 과정에서 팀의 화합된 멘탈 모델을 만들 수 있다. 열려 있는 대화, 탐구 그리고 현재의 지식 기반에 대한 도전의 결과는 핵심 도메인에 대한 더 깊은 통찰로 이어질 것이다.

- Domain-Driven Design Distilled, 반 버논 p58

 

도메인 전문가와 함께 헤야 하는 이유는 계속해서 강조되고 있다. 반드시 그래야 한다. 분석 단계 처음터. Event Storming 과 같은 Workshop을 만들어서라도. 그렇게 Workshop 기반으로 ASIS, TOBE, BC/MS 등을 정리해 가면 문서 기반이 아닌 함께 만든 Workshop 결과물을 계속 보며 논의할 수 있다 (Living Document). 이로 인해 위의 제안과 같은 대화, 탐구, 지식기반, 더 깊은 통찰로 이어질 수 있다

Event Storming ASIS -> TOBE, CSD, SRD, SD -> API First Design -> 상세설계 및 개발, 이렇게 자연스럽게 개발로 연결된다