This is an old revision of the document!
Ubiquitous Language의 변화가 곧 모델의 변호라는 것을 인식하라. 도메인 전문가는 도메인을 이해하는 데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다. 개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내는데 촉각을 곤두세워야 한다.
요구사항이나 설계를 위한 논의에 참석하게 되어 경청했을 때, 공통 언어를 쓰고 있는가?
모델을 정제하는 가장 좋은 방법은 가능한 모델 변경을 구성하는 다양한 요소를 큰소리로 말하면서 말하기를 통해 살펴보는 것이다
Ubiquitous Language를 논의(특히 개발자와 도메인 전문가가 시나리오와 요구사항에 대해 충분한 이야기를 나눠 해결하고자 하는)할 때 사용하면 ... 자연스럽게 다이어그램만으로는 일어날 수 없는 방식으로 말로써 언어를 공유하게 되는 것이다
개발자와 도메인 전문가(혹은 사용자) 사이에 공유된 동일한 도메인 모델에 공통 언어를 사용해라
모델의 핵심은 도메인 전문가의 관심을 끌어야 한다. …
도메인 전문가는 해당 분야에 대해 다소 심층적으로 사고할 수 있는 능력을 갖추고 있다고 봐야 한다. 수준 높은 도메인 전문가도 해당 모델을 이해하지 못한다면 모델이 잘못된 것이다.
다이어그램은 모델을 설명하는 수단으로 사용하고, 세부사항은 코드에 반영하라.
문제는 사람들이 UML을 통해서만 객체 모델이나 설계를 전달해야 한다는 강박감을 느낄 때 생긴다.
많은 객체 모델 다이어그램은 지나치게 완전한 동시에 많은 부분이 생략돼 있다. 객체 모델이 지나치게 완전해지는 까닭은 사람들이 앞으로 코딩할 것들을 모조리 모델링 툴에 집어넣어야 한다고 생각하기 때문이다. 이러한 세부 사항이 너무 많으면 어느 누구도 나무만 보고 숲은 보지 못한다.
하지만 그러한 모든 세부사항에도 불구하고 속성과 관계는 객체 모델의 절반에 불과하다. 이러한 객체의 행위(behavior)와 제약 조건(constraint)은 그렇게 쉽게 설명되지 않는다. 객체 상호작용 다이어그램은 설계에서 까다로운 부분들(tricky hostpots)을 설명할 수 있지만, 대부분의 상호작용은 그런 방식으로 표현할 수 없다. 다이어그램을 만들고 또 그것들을 해석하자면 해야 할 일이 너무 많다. 그리고 다이어그램은 여전히 모델의 목적을 암시하는 데 그친다. 제약 조건과 단언(assertion)까지 포함하려면 텍스트를 작은 괄호에 감싸서 다이어그램에 집어넣는 수밖에 없다.
모델은 다이어그램이 아니라는 점을 항상 명심해야 한다.
(다이어그램은 모델을 전달/설명하기 위한 수단일뿐이다.) …
잘 작성된 코드는 UML만큼 표현력이 있다.
문서를 평가하는 두 가지 일반적인 지침
문서는 거들뿐.
그러나 설계 문서로서의 코드는 한계가 있다. 코드를 읽는 이는 코드의 세부사항에 압도될 수 있다. 코드의 행위에 모호함이 없다고 해서 코드를 이해하기가 쉽다는 것은 아니다. 그리고 이면에 존재하는 의미는 전달하기 어렵다.
코드가 이미 세부 사항을 제공하고 있다. 코드는 프로그램의 행위를 정확하게 규정한 명세에 해당한다.
공통 언어를 쓰는 최소한의 문서와 세부사항을 담는 코드를 작성하고, 항상 동기화하라.
이를 판단하는 가장 쉬운 방법은 문서가 Ubiquitous Language와 상호작용하는지 살펴보는 것이다. 문서가
코드가 전달하는 메시지/의미 또한 신경써라
올바르게 실행되는 것뿐만 아니라 올바른 의미를 전달하는 코드를 작성하자면 엄청나게 세심한 노력을 기울어야 한다.
이 책의 요점은 하나의 모델이 구현, 설계, 의사소통의 기초가 대야 한다는 것이다.