• 모델은 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서
  도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다.
  • 이러한 용어와 상호관계는 기술적인 개발을 할 수 있을 만큼 충분히 정확한 동시에 도메인에 맞게 조정된 언어의 의미체계를 제공한다.
  • 모델 기반 의사소통은 UML상의 다이어그램으로 한정되어서는 안된다. 모든 의사소통에 스며들 필요가 있다.

  번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다

• Ubiquitous Language를 구성하는 어휘
  • 클래스와 주요한 연산의 이름
  • 모델 내에서 명시적으로 드러나는 규칙을 토론하기 위한 용어
  • 모델에 부과된 높은 수준의 구성 원칙(14장과 16장엣 논의할 Context Map과 대규모 구조 같은)에서 비롯된 용어
  • 팀에서 일반적으로 사용하는 도메인 모델에 적용하는 패턴의 이름

• 모델 기반 언어는시스템의 산출물뿐 아니라 업무와 기능을 기술할 때도 사용해야 한다.
  • 다이어그램과 문서에서, 그리고 특히 말할 때 동일한 언어를 사용하라.

  Ubiquitous Language의 변화가 곧 모델의 변호라는 것을 인식하라.
  
  도메인 전문가는 도메인을 이해하는 데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다.
  개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내는데 촉각을 곤두세워야 한다.

• 예제 : 화물의 운송 항로 고안하기 → 사용자와 개발자가 동일한 언어로 이야기 하는가?
  • 소프트웨어가 업무에 어떤 의미를 주는가? → 사용자 == 도메인
  • 소프트웨어가 기술적으로 어떻게 동작하는가? → 개발자

요구사항이나 설계를 위한 논의에 참석하게 되어 경청했을 때, 공통 언어를 쓰고 있는가?

  모델을 정제하는 가장 좋은 방법은
  가능한 모델 변경을 구성하는 다양한 요소를
  큰소리로 말하면서
  말하기를 통해 살펴보는 것이다

  Ubiquitous Language를 논의(특히 개발자와 도메인 전문가가 시나리오와 요구사항에 대해 충분한 이야기를 나눠 해결하고자 하는)할 때 사용하면
  ...
  자연스럽게 다이어그램만으로는 일어날 수 없는 방식으로
  말로써 언어를 공유하게 되는 것이다