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