Domain Driven Design/Eric Evance - 2. Communication and the Use of Language

모델을 기반하는 커뮤니케이션은 UML과 같은 Diagram이 국한되어 하는 것이 아니다. 가장 효과적으로 모델을 사용하기 위해서 전달 방식을 스며들게 할 필요가 있다. 이것은 Text 문서의 활용성을 높일 뿐만아니라 에자일 프로세스에서 비형식적이고 캐쥬얼한 의사소통을 가능케한다. 이를 Ubiquitous Language라고 한다. 

모델에 대한 설명의 비용, 오해의 리스크는 매우 높으므로 프로젝트에는 튼튼한 공통된 언어가 필요하다. 팀이 도메인 모델에 공을 많이 들이면 도메인 모델은 커뮤니케이션의 주측이 될 수 있다. 이것이 유비쿼터스 언어라고 할 수 있다. 

초기 모델은 유비쿼터스 커뮤니케이션을 수용하기에는 부족한 수준으로 간결할 것이다. 해당 분야의 특정 용어에 대해서도 풍부하게 의미전달을 못할것이다. 하지만 그 용어들은 모호함과 모순을 갖고 있기에 단독으로 사용될 수도 없다. 그리고 개발자들이 구현한 내용을 담기에 디테일이 부족하다. 

모델을 언어의 중추로 사용하라. 프로젝트 팀을 가차없이 모델을 사용하여 커뮤니케이션 하도록 연습시켜라. 같은 언어로 말하고 쓰고 발표하도록 하라. 도메인 전문가는 도메인에 적용하기에 어색하거나 부적적한 용어나 구조를 반대해야할 필요가 있다. 또한 개발자들은 모호함이나 일관되지 않는 것들이 Design에 반영되는지에 대해 감시할 필요가 있다. 

Model Out Loud

Speech를 다른 커뮤니케이션 형식에서 분리시키게 되면 추후에 큰 Loss가 발생한다. 사람은 Speech에 유능한 재능을 갖고 있어 자칫 잘못하면 Domain 모델을 무시하고 용어를 선택하는 경우가 발생할 수 있다. 비록 용어나 구조가 비 전문적인 단계라도 Speech을 통해 밖으로 표출시켜야 정제작업이 수월하다.  

시스템을 이야기할때 모델을 가지고 놀기를 바란다. 시나리오를 서술할때 모델에 녹아있는 구성요소와 상호작용을 사용하여 과감히 서술하라. 말하고자 하는 내용을 표현하는 가장 쉬운 방법을 찾고 새로운 아이디어는 모델내의 다이어그램과 코드로 남겨라.

One Team, One Language
하나의 유비쿼터스 언어를 통해 개발자간이나 도메인 전문가간의 커뮤니케이션에도 공유된 도메인 모델과 같은 언어를 기초하여야한다. 

Documents and Diagrams
UML 다이어그램은 오브젝트의 관계를 설명하기에 매우좋은 도구이다. 그러나 그것들로 개념적인 정의까지 표현하는데는 한계가 있다. 따라서 나의 경우 그런 개념적인 정의까지 살을 붙여 미팅에 임하곤한다. 

UML을 모든 모델에 강제하다보면 문제가 발생할 수 있다. 왜냐하면 사람들은 UML은 모든 오브젝트를 다 갖고 있어야 한다고 생각하기 때문이다. 그런데 이런 방식은 숲을 보지 못하고 나무만 보게 되는 오류가 발생할 수 있다. 그리고 오브젝트의 행위와 제약사항을 시각화 하기에는 한계가 있다. 

이렇게 코드 생성력을 가진 모델링 툴은 역효과가 발생하는 경우를 많이 보았다. 다이어그램 커뮤니케이션과 설명의 수단이다. 그리고 그것들은 브레인스토밍을 가능케 한다. 즉 UML처럼 모든 오브젝트를 나열할것이 아니라 개념적으로 디자인에서 필수적인 부분을 단순화된 다이어그램이어야 한다. 이런 방식은 포인트를 명확화 시키기 위해 단순화하고 설명적이고 심지어 표준이 아닌 표기법을 포함하기도 한다. 이것은 생각의 뼈대이며 디자인 상세설명이 아니다. 

항상 기억하라 모델은 다이어그램이 아니다. 다이어그램의 목적은 커뮤니케이션하고 설명을 돕기위함이다. 주의깊게 선별되고 구조화된 다이어그램(모든것을 표현하는 강박관념에서 벗어난)은 사람들의 관심을 집중시키고 리딩을 돕는다. 


Written Design Documents
- 문서는 Code와 Speech를 보완해야 한다.
문서는 Code가 하는 일을 해야하는게 아니며 "프로그램 행동에 대한 설명서(exact specification of program behavior)"이다.

- 문서는 생존하기 위해 변화해야 하며 최신을 유지해야 한다.
문서를 최소화 시키고 Code와 커뮤니케이션을 보완할 수 있도록 유지함으로써 문서는 계속하여 프로젝트와 연결된다. 유비쿼터스 랭기지와 이것의 변화과정을 문서를 선택하는데 도움을 줄 가이드에 남겨라

Explanatory Model(설명하기 좋은 모델)
Explanatory Model은 의사소통이 좀더 쉽도록 만든다. 시각적인 은유는 종종 명확하게 설명하는데 도움이 된다. 꼭 Explanatory Model이 객관적인 모델일 필요는 없다.