DDD에 대한 소중한 피드백
도메인 스토리텔링 응용 8
<입장에 맞춰 맥락을 나눈 BoundedContext>편에 피드백이 있었다.
BoundedConext 마다 각자의 언어가 있다고 오해할 수 있다는 지적이다. 옳은 지적이다. Ubiquitous language가 일부에서만 통용된다면 언어의 가치가 떨어진다. (언어는 소통에 쓰여야 가치가 있지 않은가?)
Bounded Context별로 언어가 있을 수는 없다
마음에 들어서 자주 인용하는 아래 그림이 오해를 유발할 수 있다. Ubiquitous Language가 Bounded Context의 하위 요소로 보일 수 있다.
내가 이 그림을 볼 때 마음에 둔 부분은 왜곡된 이해가 있었다. 나는 페이스북에 아래와 같이 즉흥적으로 댓글을 달았는데, 그림을 적극 옹호하는 사람처럼 쓴 것이다. 다시 보니 일반적으로 받아들이기 어려운 주장이다. 맥락이 달라질 때 표현을 정교하게 하라는 말이 Ubiquitous Language와 연결하기는 어렵다.
이걸 어떻게 설명할 수 있을까?
좋은 지표와 Ubiquitous Language
어제 밤에 몇몇 지인과 함께 읽었던 <린 분석>에서 나눈 대화를 인용해서 탈출구를 찾아보자. 우리는 좋은 지표에 대해 논의했다. 나의 주장은 지표는 단위처럼 통용 가능해야 한다고 말했고, 한 지인은 입장(부서)이 달라도 하나로 바라볼 수 있어야 한다고 강조했다. 나는 그 표현을 '다면적인' 이라는 단어로 바꾸어 '다면적인 단위'로 두 가지 가치를 합친 말을 만들었다.
다면적인 가치를 담을 수 있어야 통용이 된다
지표와 Ubiquitous language는 닮은 면이 있다. <린 분석>에서 말하는 지표는 사업을 어떻게 바라볼 것인가를 규정하는 핵심 산물이다. 마치 DDD 에서도 비슷한 무언가가 있어야 한다. 한 방향을 바라보는 일은 비저닝이라고 한다. 그 과정에서 모델이나 Ubiquitous language가 쓸모가 생긴다.
이 정도 배경 지식을 맞추고 다시 저 문장을 바라보자. 다면적인 가치를 어떻게 담을 수 있을까? 다면이란 말은 무슨 말인가? 입장이 다른 상황을 면이 여러 개라고 묘사할 수 있다. 그때 다면성을 확보하려면 입장이 달라도 즉, Bounded Context가 여러 개더라도 서로 하나로도 동작할 수 있어야 한다.
Context Map 소개
10 여년 전에 엄청 좋아했던 책인 DDD 원서는 아직도 소장중이다. 한때 Eric Evans와 메일 교환도 하며 꿈을 키웠지만 결국 한국에서 실현을 못했다. 그렇게 잊고 살던 일이 MSA 유행과 함께 다시 돌아왔다. DDD 책은 4개 구성요소로 나뉜다. 그 중 4부에 맥락(Context)에 대한 이야기가 나온다.
나는 그에 대한 배경 지식을 보급하려고 <입장에 맞춰 맥락을 나눈 BoundedContext>편을 썼는데 호주에 사시는 페친님이 진지하게 DDD를 공부하다 의견을 올리셨다.
이걸 엮어가기 위해서는 교집합은 Core Design, 소통법은 Ubiquitous Language(디지털 훈민정음) 그리고 모델 중심으로(지표로 소통하는) 설계(의사결정)을 하자는 것이 DDD다. 그걸 위해 Context 실체화를 위해 중요한 요소가 3가지이다.
하나는 입장에 맞춰 맥락을 나눈 BoundedContext (선택과 집중), 두 번째는 지속적으로 협력하기(a.k.a. CI/CD/DevOps) 그리고 마지막이 바로 ContextMap 이다. (Context Map은 독자의 요청이 있을 때 다룹니다.)
지난 도메인 스토리텔링 응용
6. 도메인 모델, Ongoing 설계 그리고 정원관리
7. 입장에 맞춰 맥락을 나눈 BoundedContext
