[도메인 주도 설계] 02. 의사소통과 언어 사용

UBIQUITOUS LANGUAGE (보편언어)

• 도메인 모델은 소프트웨어 프로젝트를 위한 공통 언어의 핵심
• 모델 기반의 의사소통은 통합 모델링 언어(UML) 상의 다이어그램으로 한정되어서는 안된다.
• 유연하고 풍부한 지식이 담긴 설계를 만들려면 다용도로 사용할 수 있는 팀의 공유 언어와 그 언어에 대한 활발한 실험이 필요하다.

공통 언어가 없는 프로젝트의 문제점

• 도메인 전문가는 원하는 바를 모호하게 설명하고, 개발자가 이해하는 바도 모호한 수준에 머문다.
• 도메인 전문가와 개발자가 서로 자신들의 언어를 번역해줘야 하며, 이또한 정확하지 않다.
• 의사소통이 직접적으로 일어나지 않기 때문에 개념이 분열돼도 겉으로 드러나지 않는다.
• 번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다.

유용한 모델을 만들기위한 노력

• 모델을 언어의 근간으로 사용해야 한다. 팀 내 모든 의사소통과 문서에 사용해야 한다.
• 대안이 되는 표현을 시도하며 대안 모델을 반영한다. 그리고 새로운 모델에 맞게끔 코드를 리팩터링한다.
• UBIQUITOUS LANGUAGE의 변화가 곧 모델의 변화
• 도메인 전문가는 도메인을 이해하는 데 부자연스럽거나 부정확한 용어나 구조에 대해 주의한다.
• 개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내야한다.

예제-화물의 운송 항로 고안하기

• 시나리오 1 모델에 비해 시나리오 2 모델을 기반으로 의사소통하면 "운항일정(Itinerary)" 객체와 "항로설정명세(Route Specification)" 객체를 통해 더 명확하게 논의를 이끌어 나갈 수 있다.

크게 소리내어 모델링하기

• 직접 소리내어 말하기를 통해 살펴보면, 다듬어지지 않은 표현을 쉽게 분간할 수 있다.
  1. "Routing Service에 출발지, 목적지, 도착 시간을 전달하면 화물이 멈춰야 할 지점을 찾고, 그것을 데이터 베이스에 삽입한다"(모호하고 기술적임)
  2. "출발지, 목적지, 등등... 이것들을 모두 Routing Service에 넣으면 필요한 것이 모두 담긴 Itinerary를 돌려받는다"(좀더 완전해졌지만, 장황함)
  3. "Routing Service는 Route Specification을 만족하는 Itinerary를 찾는다" (간결함)
• 표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 새로운 아이디어를 다이어그램과 코드에 적용한다.

한 팀, 한 언어

• 종종 기술담당자는 업무 전문가에게 도메민 모델을 보여줄 필요가 없다고 생각한다.
• 설계에는 도메인 전문과와 관련이 없는 기술적인 구성요소도 있지만 모델의 핵심은 도메인 전문가의 관심을 끌어야한다.
• 수준 높은 도메인 전문가도 해당 모델을 이해하지 못한다면 모델이 뭔가 잘못된 것이다.
• 모든 논의에서 이 언어를 사용하면 함께 모델을 검증할 기회가 마련되고 점차 서로의 개념 이해와 정제가 깊어진다.
• 도메인 전문가는 모델의 언어를 바탕으로 유스케이스를 작성하고, 인수 테스트를 구체화함으로써 모델을 훨씬 더 직접적으로 다룰 수 있다.
• UBIQUITOUS LANGUAGE의 확장 영역에는 개발자의 기술 용어나 사용자의 전문 용어들이 포함될 수 있다. 이 영역의 언에는 별개의 모델을 반영하면서 같은 도메인에서 쓰이는 대체 어휘가 포함되어 있어서는 안된다.

문서와 다이어그램

• UML 다이어그램은 객체 간의 관계를 전달하고 상호작용을 표현하는데 알맞다.
• 하지만 UML은 모델이 나타내는 개념의 의미와 모델 내 객체의 행위를 전하지는 못한다.
• 다이어그램으로 설계를 완벽하게 표현하려다보면, 모델의 중요한 부분들이 생략되고 모호해진다.
• 전체 객체 모델을 전부 포괄하는 다이어그램은 의사소통이나 설명이라는 목적을 달성하지 못한다.
• 모델은 다이어그램이 아니며, 다이어그램의 목적은 모델을 전달하고 설명하는 데 있다.

글로 쓴 설계 문서

• 글로 쓴 문서는 안정과 공유에 도움이 된다.
• 하지만 문서가 일단 변하지 않는 형태를 취하게되면 프로젝트 흐름과의 연관성을 잃어버리기 쉽다.
• 문서가 코드의 발전이나 프로젝트 언어의 발전에 뒤처지는 것이다.
• 문서는 코드와 말을 보완하는 역할을 해야한다.
  • 익스트림 프로그래밍에서는 코드 스스로 별도의 설명이 필요없는 상태를 유지해야한다는 입장이다. 
  • 외부 문서와 다이어그램, 심지어 주석도 프로그램의 행위에 영향을 주지 못하므로 일관성을 잃어버린다.
  • 하지만 설계 문서로서의 코드는 한계가 있다.
    • 코드를 읽는 이는 코드의 세부사항에 압도될 수 있다.
    • 코드가 모호하지 않다고해서 이애하기 쉽다는 것은 아니다.
    • 행위의 이면에 존재하는 의미는 전달하기 어렵다.
  • 문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안된다. 코드는 프로그램의 행위를 정확하게 규정한 명세에 해당한다.
  • 다른 문서들은 의미를 설명하고, 대규모 구조에서 통찰력을 주며, 핵심 요소에 집주할 필요가 있다.
• 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.
  • 문서는 프로젝트 활동과 관련을 맺고 있어야 한다.
    • 문서가 현재 쓰는 언어로 작성되어 있는가?
    • 문서가 코드에 포함된 언어로 쓰여 있는가?
  • UBIQUITOUS LANGUAGE를 바탕으로 하면 요구사항 명세와 같은 문서는 좀 더 간결해지고 덜 모호해진다. 
  • 문서를 최소한으로 유지하고 코드와 대화를 보완하는 데 집중함으로써 문서는 프로젝트와 연관된 상태로 유지할 수 있다.

실행 가능한 기반

• 코드는 의미 전달에 매우 충실하지만, 코드가 전달하는 메시지가 정확하다는 보장은 없다.
• 올바르게 실행되는 것뿐만 아니라 올바른 의미를 전달하는 코드를 작성하자면 세심한 노력을 기울여야 한다.
• 그럼에도 코드는 다른 문서보다 기반 역할을 감당하는데 유리하다.
• 의사 소통을 효과적으로 하려면 코드는 요구사항을 작성하는 데 사용하고, 커뮤니케이션할 때 사용하는 것과 동일한 언어에 기반을 둬야한다.

설명을 위한 모델

• 하나의 모델이 구현, 설계, 의사소통의 기초가 돼야한다. 각 목적에 각기 다른 모델을 갖추는 것은 바람직하지 않다.
• 설계를 위한 기술적 모델은 해당 기능을 수행하는 데 필요한 최소한의 수준으로 엄격하게 범위를 줄여야 한다.
• 반면 설명을 위한 모델은 도메인의 여러 측면을 포함할 수 있으며, 이러한 측면들은 더욱 좁은 범위의 모델을 명확하게 하는 맥락을 제공한다.
• 설명을 위한 모델과 설계를 주도하는 모델이 상응하더라도 비슷함이 정확함을 담보하지는 않는다. 혼동을 피하려면 이 둘의 차이를 의식하고 있어야 한다.

예제 - 해운 활동과 항로

• 설계를 위한 클래스 다이어그램은 업무경험이 없는 사람이 이해하기에는 적합하지 않다.
• 설명을 위한 모델은 클래스 다이어그램과 상세하게 대응하지는 않지만 도메인의 핵심 개념을 밝히는데 도움을 준다.
• 개별 관점으로 바라볼 때보다 이 둘이 함께할 때 더 이해하기 쉽다.