domain-driven-design

02장. 의사소통과 언어 사용

Introduction

• 도메인 모델은 소프트웨어 프로젝트를 위한 공통 언어의 핵심이 될 수 있다.
• 모델 기반 의사소통은 통합 모델링 언어 (Unified Modeling Language, UML) 상의 다이어그램으로 한정돼서는 안된다.
• 모델을 가장 효과적으로 사용하려면 모든 의사소통 수단에 스며들 필요가 있다.
• 프로젝트에서 언어를 사용하는 것은 미묘하지만 아주 중요하다.
• UBIQUITOUS LANGUAGE (보편 언어)
• 유연하고 풍부한 지식이 담긴 설계를 만들려면 다용도로 사용할 수 있는 팀의 공유 언어와 그 언어에 대한 활발한 실험이 필요하다.
• 하지만 아쉽게도 소프트웨어 프로젝트에서는 그와 같은 실험이 거의 일어나지 않는다.
• 프로젝트에서 사용하는 언어가 분열되면 심각한 문제가 발생한다.
• 도메인 전문가는 자신의 전문 용어를 사용하고, 기술적인 업무를 맡은 팀원들은 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 언어를 사용한다.
• 일상적인 토론에서 쓰이는 용어가 코드(궁극적으로 가장 중요한 소프트웨어 프로젝트 산출물)에 녹아든 용어와 단절된다.
• 그리고 같은 사람인데도 말할 때나 글을 쓸 때 서로 다른 용어를 써서 도메인의 가장 간결하고 명확한 표현이 일시적인 형태로 나타났다가 코드나 문서에도 담기지 않는 결과가 나타나기도 한다.
• 번역은 의사소통을 무디게 하고 지식 탐구를 빈약하게 만든다.
• 이처럼 일부 사람들만 쓰는 언어는 모두의 필요를 충족하지 못하므로 공통 언어가 될 수 없다.
• 모델 기반 언어는 개발자 사이에서 시스템의 산출물뿐 아니라 업무와 기능을 기술할 때도 사용해야 한다.
• 지식 탐구 과정을 통해 실험을 하다보면 언어에 공백을 발견하여 새로운 단어가 나타날 것
• 이러한 언어의 변화는 도메인 모델의 변화로 인식될 것
• 개발자들은 구현이라는 맥락에서 이러한 언어를 사용하고 의미가 부정확하거나 모순되는 사항을 지적해서 도메인 전문가가 실행 가능한 대안을 생각해 내게끔 만들 것
• 모델을 언어의 근간으로 사용하라.
• 팀 내 모든 의사소통과 코드에서 해당 언어를 끊임없이 적용하는 데 전념하라.
• 다이어그램과 문서에서, 그리고 특히 말할 때 동일한 언어를 사용하라.
• 대안 모델을 반영하는 대안이 되는 표현을 시도해 봄으로써 어려움을 해소하라.
• 그런 다음 새로운 모델에 맞게끔 클래스, 메서드, 모듈의 이름을 다시 지으면서 코드를 리팩터링하라.
• 일상적으로 쓰는 단어의 의미에 동의를 이끌어내는 것과 같은 방식으로 대화할 때 쓰는 언어의 혼란도 해결하라.
• UBIQUITOUS LANGUAGE 의 변화가 곧 모델의 변화라는 것을 인식하라.
• 도메인 전문가는 도메인을 이해하는 데 부자연스럽고 부정확한 용어나 구조에 대해 반대 의사를 표명해야 한다.
• 개발자는 설계를 어렵게 만드는 모호함과 불일치를 찾아내는 데 촉각을 곤두세워야 한다.

크게 소리내어 모델링하기

• 모델을 정제하는 가장 좋은 방법은 가능한 모델 변형을 구성하는 다양한 요소를 큰 소리로 말하면서 말하기를 통해 살펴보는 것
• 다이어그램을 그려서 시각적/공간적 추론 능력을 활용하는 것이 중요한 것과 마찬가지로 모델링할 때 우리의 언어 능력을 활용해 단어와 구절을 곱씹어보는 것도 절대적으로 필요
• UBIQUITOUS LANGUAGE 패턴의 추가사항
  • 시스템에 관해 이야기를 주고받을 때 모델을 사용하라.
  • 모델의 요소와 상호작용을 이용하고 모델이 허용하는 범위에 개념을 조합하면서 시나리오를 큰 소리로 말해보라.
  • 표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 그러한 새로운 아이디어를 다이어그램과 코드에 적용하라.

한 팀, 한 언어

• 모델의 핵심은 전문가의 관심을 끌어야 한다.
• 수준 높은 도메인 전문가도 해당 모델을 이해하지 못한다면 모델이 뭔가 잘못된 것이다.
• 개발자와 도메인 전문가는 시나리오를 토대로 모델 객체를 단계적으로 사용해 보면서 비공식적으로 모델을 시험해볼 수 있다.
• 거의 모든 논의에서 개발자와 사용자 전문가가 함께 모델을 검증할 기회가 마련되고 점차 서로의 개념 이해와 정제가 깊어진다.
• 도메인 전문가는 모델의 언어를 바탕으로 유스케이스를 작성하고, 인수 테스트를 구체화함으로써 모델을 훨씬 더 직접적으로 다룰 수 있다.
• 애자일 프로세스에서는 애플리케이션을 충분히 구체화할 지식을 초반에 갖출 수 있는 경우가 거의 없으므로, 프로젝트가 진행되면서 요구사항 또한 발전한다고 본다.
• 때로는 여러 언어가 필요할 때도 있지만, 도메인 전문가와 개발자 사이에 언어적 분열이 일어나서는 안된다.
• UBIQUITOUS LANGUAGE 가 마련되면 개발자 간의 대화, 도메인 전문가 간의 논의, 코드 자체에 포함된 표현까지 이 모든 것이 공유된 도메인 모델에서 비롯된 동일한 언어를 기반으로 한다.

문서와 다이어그램

• 간결하고 형식에 얽매이지 않은 UML 다이어그램은 논의의 구심점 역할을 할 수 있다.
• 문제는 사람들이 UML 을 통해서만 전체 모델이나 설계를 전달해야 한다고 느낄 때 생긴다.
• UML 다이어그램은 모델의 가장 중요한 두 가지 측면을 전달할 수 없는데, 그것은 바로 모델이 나타내는 개념의 의미와 모델 내 객체의 행위
• UML 은 아주 만족스러운 프로그래밍 언어도 아님
• 다이어그램은 의사소통과 설명의 수단이며 브레인스토밍을 촉진함
  • 이러한 목적은 다이어그램이 최소화됐을 때 가장 잘 달성됨
• 설계의 생생한 세부사항은 코드에 담긴다.
• 모델은 다이어그램이 아니라는 점을 항상 명심해야 한다.
  • 다이어그램의 목적은 모델을 전달하고 설명하는 데 있음

글로 쓴 설계 문서

• 문서를 평가하는 두 가지 일반적인 지침

1. 문서는 코드와 말을 보완하는역할을 해야 한다.
   • 문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안된다.
   • 코드는 이미 세부사항을 충족한다.
   • 코드는 프로그램의 행위를 정확하게 규정한 명세에 해당한다.
2. 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.
   • 문서는 프로젝트 활동과 관련을 맺고 있어야 한다.
   • 이를 판단하는 가장 쉬운 방법은 문서가 UBIQUITOUS LANGUAGE 와 상호작용하는지 살펴보는 것

실행 가능한 기반

• 올바르게 실행되는 것뿐만 아니라 올바른 의미를 전달하는 코드를 작성하자면 엄청나게 세심한 노력을 기울어야 한다.
• 코드도 물론 잘못된 방향으로 유도할 수 있다.
• 그럼에도 코드는 다른 문서보다 기반 역할을 감당하는 데 유리하다.

설명을 위한 모델

• 이 책의 요점은 하나의 모델이 구현, 설계, 의사소통의 기초가 돼야 한다는 것
• 이러한 각 목적에 각기 다른 모델을 갖추는 것은 바람직하지 않음
• 모델은 도메인을 가르치는 도구로도 아주 유용할 수 있음
• 다른 모델이 필요한 이유 가운데 특별한 한 가지는 바로 범위 때문
• 설명을 위한 모델에서는 특정 주제에 맞춰 훨씬 더 전달력이 높은 의사소통 방식을 마음껏 만들어 낼 수 있음
• 설명을 위한 모델이 꼭 객체 모델일 필요는 없으며, 오히려 그렇지 않을 때가 일반적으로 가장 좋음
  • 실제로 이러한 모델에서는 UML 사용을 자제하고 UML 과 소프트웨어 설계와의 관련성에 관해 잘못된 인상을 주지 않는 것이 좋다.