2장

하나의 모델이 구현, 설계, 의사소통의 기초가 돼야 한다.

25p

프로젝트에서 사용하는 언어가 분열되면 심각한 문제가 발생한다. 도메인 전문가는 자신의 전문 언어를 사용하고 기술적인 업무를 맡은 팀원들은 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 언어를 사용한다.

일상적인 토론에서 쓰이는 용어가 코드에 녹아든 용어와 단절된다. 그리고 같은 사람인데도 말할 때나 글을 쓸 때 서로 다른 용어를 써서 도메인의 가장 간결하고 명확한 표현이 일시적인 형태로 나타났다가 코드나 문서에도 담기지 않는 결과가 나타나기도 한다.

27p

그러므로 모델을 언어의 근간으로 사용하라. 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는 데 전념하라. 다이어그램과 문서에서, 그리고 특히 말할 때 동일한 언어를 사용하라.

UBIQUITOUS LANGUAGE의 변화가 곧 모델의 변화라는 것을 인식하라

37p

문서와 다이어그램 모델은 다이어그램이 아니라는 점을 항상 명심해야 한다. 다이어그램은 의사소통과 설명의 수단이며 브레인 스토밍을 촉진한다. 이러한 목적은 다이어그램이 최소화됐을 때 가장 잘 작성된다.

39p

글로 쓴 설계 문서 문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안 된다. 설계 문서의 가장 큰 가치는 모델의 개념을 설명하고, 코드의 세부사항을 파악해 나가는 데 도움을 주며, 어쩌면 모델의 의도된 사용 방식에 어떤 통찰력을 주는 데 있다.