모델 기반 의사소통은 통합 모델링 언어(Unified Modeling Language, UML)상의 다이어그램으로 한정돼서는 안된다.

보편언어(UBIQUITOUS LANGUAGE)

• 프로젝트에서 사용하는 언어가 분열되면 심각한 문제가 발생한다. 도메인 전문가는 자신의 전문 용어를 사용하고 기술적인 업무를 맡은 팀원들은 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 언어를 사용
• 일상적인 토론에서 쓰이는 용어가 코드(궁극적을 가장 중요한 소프트웨어 프로젝트 산출물)에 녹아든 용어와 ㄷ나절. 그리고 같은 사람인데도 말할 때나 글을 쓸 때 서로 다른 용어를 써서 도메인의 가장 간결하고 명확한 표현이 일시적인 형태로 나타났다가 코드나 문서에도 담기지 않는 결과가 나타나기도 한다.
• 번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다.

하이라이트

• 모델을 언어의 근간으로 사용하라. 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는 데 전념하라. 다이어그램과 문서에서, 그리고 특히 말할 때 동일한 언어를 사용
• 대안 모델을 반영하는 대안이 되는 표현을 시도해 봄으로써 어려움을 해소하라. 그런 다음 새로운 모델에 맞게끔 클래스, 메서드,모듈의 이름을 다시 지으면서 코드를 리팩터링하라. 일상적으로 쓰는 단어의 의미에 동의를 이끌어 내는 것과 같은 방식으로 대화할 때 쓰는 용어의 혼란도 해결하라.
  => UBIQUITOUS LANGUAGE의 변화가 곧 모델의 변화라는 것을 인식하라.
• 도메인 전문가는 도메인을 이해하는 데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다. 개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내는 데 촉각을 곤두세워야 한다.

우리는 어떤 서비스의 모델링을 할 때 흔히 빠지는 함정이 있다.

바로 다이어그램, UML을 그리면 이것이 우리 서비스의 모델이라는 착각을 하게 된다. 그러나 UML, 다이어그램에도 표현할 수 없는 부분들이 존재한다. 예를 들면 객체의 속성, 행위는 구체적으로 말해주기 힘들다.

결국 요는 다음과 같다.

우리가 말하는 모델링은 어떤 형태이든 무관하다. 단 내가 말하고자 하는 부분을 명확하게 전달만 될 수 있다면,