Ch 2. Communication and the Use of Language
도메인 모델은 소프트웨어 프로젝트에서 공통 언어의 핵심이 될 수 있다. 모델은 프로젝트에 참여한 사람들의 머리속에 구축되어 있는 도메인 인사이트를 반영한 용어와 관계로 이루어진 개념들의 집합이다.
도메인 전문가는 소프트웨어 개발에 대한 기술적인 용어에 대한 이해는 제한되어 있지만, 그들만의 필드에 있는 용어를 사용한다.
반대로, 개발자들은 도메인 전문가들의 언어와는 전혀 연결되지 않는, 묘사적이고 기능적인 용어로 시스템을 이해하고 논의할 것이다.
또는 개발자들은 그들의 설계를 지원하는 추상화를 만들어 낼지도 모르지만, 도메인 전문가는 전혀 이해하지 못한다.
이와같은 언어학적인 분리로 인해서 도메인 전문가들은 그들의 요구사항을 모호하게 이야기하고, 개발자들은 그들에게 새로운 도메인을 이해하기 위해서 모호하게 이해한 상태에서 싸우게 된다. 팀 내 일부 멤버만이 두가지 언어를 다룰 수 있지만, 정보 흐름의 병목점이 되고 불완전하게 번역하게 된다.
공통의 언어가 없는 프로젝트에서 갭라자들은 도메인 전문가를 위해서 번역을 해야만 한다. 도메인 전문가들은 개발자들과 다른 도메인 전문가들 사이에서 번역을 해야만 한다. 심지어 개발자들도 서로 간에 번역을 한다. 번역은 모델의 개념을 뒤죽박죽으로 만들고, 코드 리팩토링을 파괴적으로 이끈다.
Ubiquitous Language라는 단어는 클래스 이름과 주요한 동작을 포함하고 있다. Language는 모델을 명확하게 하는 규칙을 논의하는 용어를 포함한다.
모델 기반 언어는 시스템의 형상 뿐만 아니라 태스크와 기능을 설명하기 위해서 개발자들 사이에 사용되어야 한다. 동일한 모델은 개발자들과 도메인 전문가들이 서로 커뮤니케이션하기 위한 언어로 제공되어야 한다. 그리고 도메인 전문가들 사이에서 요구사항, 개발 계획, 기능들에 대해서 커뮤이케이션하기 위해서도 필요하다.
용어가 변경되면, 도메인 모델이 변경되고, 코드 상에서 클래스 다이어그램과 클래스 이름 변경, 메소드 변경이 일어난다.
모델 기반 언어를 넘치게 사용하여 흐를 때까지 만족되지 않는 경우에는 복잡한 아이디어를 표현하기 위해 간단한 엘리먼트들을 결합하여 모델이 완전해지고, 이해가능해지도록 한다.
따라서, 모델을 언어의 백본으로 사용하라.
팀 내 커뮤이케이션과 코드 내에서 해당 언어를 광범위하게 사용하도록 약속하라. 다이어그램, 코드 작성, 특히 대화에 동일한 언어를 사용하라.
Ubiquitous Language의 변경은 모델의 변경이라는 것을 명심해야 한다.
Ubiquitous Language는 코드상에는 나타나지 않는 디자인 측면의 주요 소통 수단이다.
Bounded Context는 다른 시스템과 모델의 관계를 정의하는 것이다.
모델과 디자인에는 다른 패턴들도 적용될 수 있다.
시스템에 대해서 이야기할 때 모델로 하라. 모델 요소와 상호작용을 사용하고, 모델에서 허용된 방법으로 개념을 조합하여 시나리오를 설명하라. 말하고자 하는 것을 더 쉽게 이야기하는 방법을 찾고, 그 새로운 아이디어를 다이어그램과 코드에 다시 반영하라.
(Business Logic이나 flow를 최적화하고, 그것을 모델링한 다음, 코드로 반영)
UML 다이어그램이나 가장 많이 사용하는 클래스 다이어그램, 객체간 상호 작용 다이어그램을 이용하여 커뮤니케이션한다.
문제는 사람들이 UML을 통해서 전체 모델이나 디자인을 전달하도록 강요받는다고 느낄 때 발생한다.
다이어그램에 있는 많은 객체 모델은 너무 완벽하고, 동시에 너무 많이 생략한다. 너무 완벽해서 사람들은 모든 객체에 대 코드를 모델링 도구로 옮겨야만 한다고 생각한다.
모든 것이 상세하면, 아무도 나무만 보고 숲을 볼 수 없다.
하지만, 모든 세부사항에도 불구하고, Attribute와 Relationship은 객체 모델 스토리의 절반에 불과하다.
객체의 동작과 제약사항들은 쉽게 설명하되지 않는다. 객체간 상호동작 다이어그램은 디자인에서 까다로운 hotspot을 설명할 수 있지만, 상호작용이 많아지면 그런 방법으로는 보일 수 없다. 다이어그램을 만드는 사람이나, 그것을 읽는 사람이나 일이 너무 많아진다.
상호작용 다이어그램은 모델의 뒤에서 목적을 암시할 뿐이다.
모델이 다이어그램이 아니라는 것을 항상 기억하라. 다이어그램의 목적은 커뮤니케이션을 돕고, 모델을 설명하기 위한 것이다. 코드는 설계에 대한 세부사항의 Repository로서 제공될 수 있다. 잘 작성된 Java는 그 자체로 UML처럼 표현적이다.
Documents Should Complement Code and Speech
(문서는 코드와 말을 보완해야 한다.)
각 Agile 프로세스는 문서에 대한 자체 철학을 가지고 있다. Extreme Programming(Agile 방법론 중 하나)은 추가 디자인 문서를 전혀 사용하지 않는 것을 지지한다. 그리고 코드 그 자체로만 이야기한다. 실행중인 코드는 다른 문서와는 달리 거짓말을 하지 않는다. 실행중인 코드는 모호하지도 않다.
Extreme Programming은 프로그램의 active element(활성 요소)와 실행가능한 테스트에만 전적으로 집중한다.
하지만, 코드가 설계 문서가 되기에는 제한점이 존재한다. 세부사항으로 인해 독자를 압도할 수 있다. 동작이 모호하지 않지만, 분명하다는 것을 의미하지는 않는다. 동작의 뒤에 있는 의미는 전달되기 어려울 수 있다. 다시 말하자면, 코드를 통한 전적인 문서화는 포괄적인 UML 다이어그램을 사용함으로써 발생하는 기본적인 문제와 동일하다.
다른 문서들은 large-scale 구조에 대한 insight를 주기 위해서, 그리고 핵심 element에 대한 주의를 집중하기 위해 의미를 비출 필요가 있다.
Documents Should Work for a Living and Stay Current
(문서는 먹고 살기 위해서 일해야 하며, 현재 상태를 유지해야 한다.)
저자는 모델링 문서 작업을 할 때, 작고 주의 깊게 선택된 모델의 하위집합, 그리고 그 하위집합의 주위에 텍스트로 다이어그램을 그린다.
자연어로 할 수 있는 한, 클래스와 클래스가 가지 책임, 의미하는 맥락에서 프레임을 글자로 정의한다.
그러나 다이어그램은 개념을 객체 모델로 공식화하고 모델로 페어링할 때, 이루어진 몇 가지 선택을 보여준다.
이러한 다이어그램들은 대충 그린-심지어 손으로 그린- 어떤 것이 될 수 있다. 게다가 노력을 줄이기 위해서 손으로 그린 다이어그램은 격식이 없고 임시적으로 생각하는 장점이 있다. 일반적으로 우리의 모델 이이디어를 정말로 나타내기 때문에 커뮤니케이션에 좋다.
설계 문서의 가장 큰 가치는 모델의 개념을 설명하고, 코드의 세부 사항을 아는데 도움이 되고, 모델 사용에 대한 의도하는 스타일을 알게 하는 것이다.
문서는 프로젝트 activity에 포함되어야 한다. 이것을 판단하는 가장 쉬운 방법은 Ubiquitous Language로 문서의 상호작용을 관찰하는 것이다. 문서가 (지금) 프로젝트에서 사람들이 말하는 언어로 작성되었는가? 문서는 코드에 포함된 언어로 작성되었는가?
Explanatory Models
(설명하는 모델)
이 책의 요지는 하나의 모델이 구현, 설계, 팀 커뮤니케이션의 기반이 되어야 한다는 것이다. 이러한 여러 목적에 대해 여러 개의 모델을 가지는 것은 위험을 제기한다.
모델은 또한 도메인에 대해 가르치기 위한 교육 목적으로써 가치를 가질 수 있다. 설게를 유도하는 모델은 도메인에 대한 하나의 뷰이지만, 다른 뷰로는 단지 교육적인 도구로 사용되어 배우고자 하는 목적을 가질 수 있다. 이러한 목적으로 사람들은 소프트웨어 디자인과 무관한 다른 모델 종류를 전달하는 그림이나 글자를 사용할 수 있다.
Explanatory Model들은 특정 주제에 딱 맞는 훨씬 더 많은 커뮤니케이션 스타일을 만들기 위한 자유를 제공한다.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/821