DDD 1부 - 2

DDD 짜집기 1부 2장

의사소통과 언어 사용

모델은 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다.
이를 표현하는 방법을 UML만으로 한정하지 않고
모든 의사소통 수단에 스며들게 해야한다.

코드 자체 혹은 테스트을 기반으로 의사소통능력의 향상을 노려볼 수 있다.

UBIQUITOUS LANGUAGE

개발자의 언어와 도메인 전문가의 언어를 통합하고 더 나아가 서로 다른 언어로 인한 오해나 외곡을 막기 위해 프로젝트에 참여하는 모든 구성원이 같은 언어를 사용해야한다.

소프트웨어 프로젝트에서는 도메인 전문가와 개발자가 각자의 전문 용어를 사용하면서 서로의 의미를 제대로 이해하지 못하는 경우가 많다.
도메인 전문가는 자신의 분야에 대한 용어는 잘 알지만 개발자의 전문 용어는 익숙하지 않고, 반대로 개발자들도 도메인 전문가의 용어 의미를 정확히 파악하지 못하는 경우가 발생한다.
이러한 상황에서는 추상화나 설계가 도메인 전문가에게 잘 전달되지 않아 프로젝트의 품질에 부정적인 영향을 줄 수 있다.

공통 언어가 없는 팀에서는 개발자들이 도메인 전문가를 위해 자신의 용어를 번역해야 하고, 도메인 전문가도 개발자들 간이나 다른 전문가들과의 의사소통을 위해 번역을 해야 한다.
심지어 개발자들 사이에서도 서로 다른 용어를 사용하기 때문에 추가적인 번역이 필요할 때가 있다.
이로 인해 팀 내 의사소통이 원활하지 않아 코드에도 혼란이 발생하고, 프로젝트 전반에 걸쳐 사용하는 언어가 분열되면서 심각한 문제로 이어질 수 있다.

예를 들어, 도메인 전문가는 자신의 전문 용어를 사용하지만 기술적인 업무를 맡은 팀원들은 설계 측면에서 도메인에 관한 토론에 적합한 자신들만의 용어를 사용하게 된다.
이렇게 되면 아무리 많은 회의를 진행해도 본질적인 문제를 해결하지 못할 수 있다.
일부 사람들만 사용하는 언어는 모두의 필요를 충족하지 못해 공통 언어가 될 수 없으며, 번역 과정에서 의사소통이 흐려지고 지식 탐구가 제한될 수 있습니다.
번역에 따른 추가 비용과 오해의 위험도 커져 프로젝트의 성공을 위협할 수 있다.

따라서, 프로젝트의 원활한 진행과 성공적인 결과를 위해서는 팀원 모두가 공통의 언어를 공유하고 사용하는 것이 매우 중요하다.
공통 언어를 통해 의사소통의 효율성을 높이고, 오해를 줄이며, 지식의 깊이를 더할 수 있고, 이는 궁극적으로 코드의 품질 향상과 프로젝트의 성공적인 완수에 큰 도움이 된다.

모델 기반 언어는 개발자 간에 시스템의 산출물뿐만 아니라 업무와 기능을 기술할 때에도 반드시 사용되어야 한다.
이러한 모델은 개발자와 도메인 전문가 간의 원활한 의사소통을 가능하게 할 뿐만 아니라, 도메인 전문가들 간의 요구사항, 개발 계획, 기능에 대한 논의에도 공통의 언어를 제공해야 한다.
모델 기반 언어가 팀 내에서 널리 사용될수록 이해도는 더욱 높아지고, 협업이 원활해진다.
초기 모델은 전문 용어의 의미적 풍부함이 부족하고, 개발자가 도메인의 개념을 충분히 반영하지 못할 수 있지만, 팀 전체가 지속적으로 헌신하여 지식을 탐구하고 모델을 개선함으로써 점차 유용한 언어로 발전할 수 있다.

UBIQUITOUS LANGUAGE를 꾸준히 사용하다 보면 언어의 취약점이 드러나고, 이는 도메인 모델의 변화로 이어진다.
이러한 변화는 클래스 다이어그램 수정, 코드 리팩토링, 메서드 및 클래스 이름 변경 등 다양한 형태로 반영되며, 개발자와 도메인 전문가가 함께 협력하여 보다 정확하고 일관된 모델을 구축하는 데 기여한다.

따라서, 팀 내 모든 의사소통과 코드 작성에서 모델 기반 언어를 근간으로 삼아야 한다.
다이어그램과 문서화는 물론, 일상적인 대화에서도 동일한 언어를 사용함으로써 용어의 혼란을 최소화하고, UBIQUITOUS LANGUAGE의 변화가 곧 모델의 변화를 의미함을 인식해야 한다.

도메인 전문가는 부정확하거나 부자연스러운 용어 사용에 대해 적극적으로 피드백을 제공하고, 개발자는 설계 과정에서 발생하는 모호함과 불일치를 신속하게 해결해야 한다.

결국, 모델은 단순한 설계 산출물이 아니라 개발자와 도메인 전문가가 함께 협력하여 모든 프로젝트 단계를 원활하게 수행할 수 있도록 하는 필수적인 요소가 된다.
공통의 모델 기반 언어를 통해 팀은 더욱 효과적으로 소통하고, 고품질의 소프트웨어를 개발할 수 있게된다.

크게 소리내어 모델링하기

시스템에 관해 이야기를 주고받을 때 모델을 사용하라.
모델의 요소와 상호작용을 이용하고 모델이 허용하는 범위에 개념을 조합하면서 시나리오를 큰 소리로 말해보라.
표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 그러한 새로운 아이디어를 다이어그램과 코드에 적용하라 .

인간은 자연스럽게 구어를 사용하지만, 의사소통 시 도메인 모델의 언어를 잘 사용하지 않는다.
요구사항이나 설계 논의에서 흔히 업무 관련 전문용어나 기술적용어가 주로 사용되며, 도메인 모델의 관계나 상호작용을 표현하는 언어는 거의 들을 수 없다.
이는 의사소통의 효율성을 떨어뜨리고, 도메인 모델의 잠재력을 충분히 활용하지 못하게 된다.
이러한 문제를 인식하고 도메인 모델 언어 사용을 장려해야한다.

모델을 정제하는 가장 좋은 방법은 가능한 모델 변형을 구성하는 다양한 요소를 큰 소리로 말 하면서 말하기를 통해 살펴보는 것이다. 다듬어지지 않은 표현은 쉽게 분간할 수 있다.

모델링할 때 다이어그램을 그려 시각적이고 공간적인 추론 능력을 활용하는 것이 중요한 것처럼, 언어 능력을 활용해 단어와 구절을 깊이 있게 분석하는 것도 필요하다.
이는 체계적인 분석과 설계 과정에서 우리의 분석 역량과 코드와 관련된 직관을 활용하는 것과 동일한 맥락이다.
이러한 사고방식은 서로 보완하며, 효과적인 모델과 설계를 찾는데 모두 필요하다.
그럼에도 불구하고, 언어를 활용한 실험은 종종 간과되는 경우가 많다.

사업상 서로 다른 언어적 배경을 가진 사람들이 모일 때 공통 언어가 없으면 혼성어(피진)를 사용하게 된다.
피진은 화자의 모국어만큼 포괄적이지 않지만, 당면한 문제를 해결하는데 적합하다.
대화 중 사람들이 단어 해석과 의미에서 발생하는 차이를 자연스럽게 발견하고 이를 원활하게 조정할 수 있다.
즉, 언어적 불편함을 찾아내어 부드럽게 해결하는 과정이다.
이러한 피진의 사용은 다양한 언어적 배경을 가진 팀이 효율적으로 소통할 수 있게한다.

도메인 모델에서 사용하는 UBIQUITOUS LANGUAGE를개발자와 도메인 전문가가 시나리오와 요구사항을 충분히 논의하며 사용하면, 해당 언어를 더욱 유창하게 구사할 수 있고 서로의 미묘한 언어 차이도 이해하게 된다.
이는 단순히 다이어그램이나 문서로는 얻기 힘든 구체적인 언어 공유를 가능하게한다.

하지만 소프트웨어 프로젝트에 UBIQUITOUS LANGUAGE를 적용하는 것은 쉽지 않은 일이다.
이를 성공적으로 구현하기 위해서는 우리의 언어적 재능을 최대한 발휘해야 한다.

한 팀, 한 언어

종종 기술 담당자는 업무 전문가에게 도메인 모델을 보여 줄 필요가 없다고 생각한다. 그들은 이렇게말한다.
"업무 전문가들에게는 너무 추상적이라서요."
"업무 전문가들은 객체를 이해하지 못해요."
"업무 전문가들이 쓰는 용어로 된 요구사항을 만들어야 해요."
이는 팀에 두 가지 언어가 존재해야 하는 이유로 들은 이야기 중 일부에 불과하다. 이런 말은 귀담아 듣지 않아도 된다.
물론 설계에는 도메인 전문가와 직접 관련이 없는 기술적 요소들도 포함될 수 있지만, 모델의 핵심은 도메인 전문가의 관심을 끌어야 한다.
"너무 추상적이다"라고 느낀다면, 그 추상화가 제대로 이루어졌는지 어떻게 확인할 수 있는가?
도메인 전문가만큼 도메인을 깊이 이해하고 있는가?
특정 요구사항은 하위 사용자로부터 수집하고 도메인 전문가에게는 더 구체적인 용어가 필요할 수 있지만, 도메인 전문가는 해당 분야에 대해 깊이 있게 사고할 수 있는 능력을 갖추고 있다고 가정해야 한다.
만약 수준 높은 도메인 전문가조차 모델을 이해하지 못한다면, 그 모델이 뭔가 잘못된 것이다.

초기 단계에서는 논의에 사용할 모델이 존재하지 않아 도메인 전문가와 개발자가 함께 새로운 아이디어를 검토하면서 모델을 찾아가는 과정이 시작된다.
이 과정은 처음에는 부자연스럽고 완전하지 않을 수 있지만, 점차 정제되어간다.
새로운 언어가 발전함에 따라 도메인 전문가는 이를 채택하고 기존의 중요한 문서들을 개정하는 데 특별한 노력을 기울여야 한다.

도메인 전문가가 개발자나 다른 도메인 전문가와 논의할 때 이 언어를 사용하면 모델에서 요구사항에 맞지 않거나 잘못된 부분을 빠르게 발견할 수 있다.
또한, 개발자의 도움을 받아 모델 기반 언어의 정밀함 덕분에 도메인 전문가 자신도 자신의 생각 중 모순되거나 모호한 부분을 깨닫는데 도움이 된다.
이를 통해 보다 정확하고 일관된 도메인 모델을 구축할 수 있다.

개발자와 도메인 전문가는 시나리오를 토대로 모델 객체를 단계적으로 사용해 보면서 비공식적으로 모델을 시험해볼 수 있다.
거의 모든 논의에서 개발자와 도메인 전문가가 함께 모델을 검증할 기회가 마련되고 점차 서로의 개념 이해와 정제가 깊어진다.
도메인 전문가는 모델의 언어를 바탕으로 유스케이스를 작성하고, 인수 테스트를 구체화함으로써 모델을 훨씬 더 직접적으로 다룰 수 있다.

도메인 모델은 통상 도메인 전문가의 전문용어에서 비롯되지만 더 명료하고 한정된 정의로 정리될 것이다.
물론 도메인 전문가는 이러한 정의가 해당 분야의 통념에서 벗어나면 이의를 제기해야 한다.
애자일 프로세스에서는 애플리케이션을 충분히 구체화할 지식을 초반에 갖출 수 있는 경우가 거의 없으므로 프로젝트가 진행되면서 요구사항 또한 발전한다고 본다.
정제된 UBIQUITOUS LANGUAGE로 요구사항을 재구성하는 일이 이러한 발전과정의 일부여야 한다.

때로는 여러 언어가 필요할 때도 있지만 도메인 전문가와 개발자 사이에 언어적 분열이 일어나서는 안된다.

UBIQUITOUS LANGUAGE가 마련되면 개발자 간의 대화, 도메인 전문가 간의 논의, 코드 자체에 포함된 표현까지 이 모든것이 공유된 도메인 모델에서 비롯된 동일한 언어를 기반으로 한다.

문서와 다이어그램

UML 다이어그램은 객체 간의 관계를 전달하는 데 특히 좋고 상호작용을 보이는 데도 알맞다. 그러나 해당 객체의 개념적 정의를 전해주지는 못한다.
회의에서 다이어그램의 밑그림을 그리면서 말로 그러한 의미를 보충하거나 다른 참석자와 대화를 나누는 과정에서 그러한 의미가 나타나곤 한다.

간결하고 형식에 얽매이지 않은 UML 다이어그램은 논의의 구심점 역할을 할 수 있다.

사람들이 다양한 사고 실험을 시도해보면서 다이어그램은 변경될 수 있고, 밑그림은 논의의 핵심 영역에 해당하는 말로 표현되는 단어들의 유동성을 어느 정도 띠게 될 것이다. 어쨌든 UML은 통합 모델링 언어를 나타내는 말이 아니던가.

문제는 사람들이 UML을 통해서만 전체모델이나 설계를 전달해야 한다고 느낄 때 생긴다.
많은 객체 모델 다이어그램은 지나치게 완전한 동시에 많은 부분이 생략돼 있다. 객체 모델이 지나 치게 완전해지는 까닭은 사람들이 앞으로 코딩할 것들을 모조리 모델링 툴에 집어넣어야 한다고 생각하기 때문이다.
이러한 모든 세부사항이 존재하는 상황에서는 어느 누구도 나무만 보고 숲은 보지 못한다.

객체의 행위(behavior)와 제약조건(constraint)은 그리기가 수월하지 않다. 객체 상호작용 다이어그램은 설계상 몇 가지 다루기 어려운 부분을 설명할 수도 있지만 상호작용의 상당수는 그러한 방식으로 표현할 수 없다.
다이어그램을 만들고 또 그것들을 해석하자면 해야 할 일이 너무 많다.
제약조건과 단언(assertion)까지 포함하려면 텍스트를 작은 괄호로 감싸서 다이어그램에 집어넣는 수밖에 없다.

즉, UML 다이어그램은 모델의 가장 중요한 두 가지 측면을 전달할 수 없는데, 그것은 바로 모델이 나타내는 개념의 의미와 모델 내 객체의 행위다.
그렇다고 이때문에 꼭 곤경에 빠진다는 의미는 아니다.

UML은 아주 만족스러운 프로그래밍 언어도 아니다.
네모와 선으로 구성된 다이어그램에는 맞지 않는다는 규칙 때문에 종종 모델의 가장 중요한 부분을 생략해야만 할 것이다.
UML을 구현 언어로 사용 한다면 정돈된 모델을 전달하는 다른 수단이 여전히 필요할 것이다.

다이어그램은 의사소통과 설명의 수단이며 브레인스토밍을 촉진한다. 이러한 목적은 다이어그램이 최소화됐을 때 가장 잘 달성된다.
전체 객체 모델을 전부 포괄하는 다이어그램은 의사소통이나 설명이라는 목적을 달성하지 못한다.

• 읽는 이를 세부사항으로 압도하고 다이어그램의 의미 또한 누락돼 있다.

이러한 이유로 저자가 작성하는 다이어그램은 설계를 이해하는 데 필수적인, 객체 모델 중 개념적으로 중요한 부분만을 나타내는 단순화된 다이어그램을 작성한다고 한다.
이 다이어그램들은 간결하고 설명적이며 심지어 핵심을 명확하게 표현하기만 하면 표준에 없는 표기법도 일부 포함하고 있다.
이 다이어그램들은 설계상의 제약조건을 보여주지만 모든 세부사항에 걸친 설계 명세는 아니다. 그것들은 아이디어의 골자를 나타낼 뿐이다.

모델은 다이어그램이 아니라는 점을 항상 명심해야 한다.
다이어그램의 목적은 모델을 전달하고 설명하는 데 있다.
잘 작성된 자바코드는 UML만큼 표현력이 있다.

글로 쓴 설계 문서

구두에 의한 의사소통은 코드의 정연함과 상세함을 의미적으로 보충하는 역할을 한다.
그러나 모든 사람을 모델에 연결되게 하는 데 말하기가 결정적인 역할을 한다고 해도 어떠한 규모의 집단이든 어느 정도는 글로 쓴 문서로 안정과 공유를 꾀할 필요가 있다.
그러나 팀이 좋은 소프트웨어를 만들어내는데 실제로 도움 될 문서를 만드는 것은 쉽지 않은일이다.

문서가 일단 어떤 변하지 않는 형태를 취하게 되면 종종 프로젝트 흐름과의 연관성을 잃어버리곤 한다.
즉, 문서가 코드의 발전이나 프로젝트 언어의 발전에 뒤처지는 것이다.

• 문서는 코드와 말을 보완하는 역할을 해야한다.

익스트림 프로그래밍은 여분의 설계 문서를 전혀 사용하지 않고 코드 스스로 별도의 설명이 필요없는 상태를 유지해야 한다는 입장을 옹호한다.
어떤 다른 문서들은 거짓말을 하는 경우가 있을지도 모르지만 실행되는 코드는 그렇지 않다. 실행되는 코드의 행위는 명백한 것이다.
오직 프로그램의 실제 동작하는 영역과 실행 가능한 테스트에만 집중한다.

이처럼 코드가 의사소통 수단의 의미를 지닌 탓에 개발자는 코드를 깔끔하고 투명하게 유지할 필요성을 느끼게 된다.

그러나 설계 문서로서의 코드에는 한계가 있다. 코드를 읽는 이는 코드의 세부사항에 압도될 수 있다.
코드의 행위에 모호함이 없다고 해서 코드를 이해하기가 쉽다는 것은 아니다. 그리고 행위 이면에 존재하는 의미는 전달하기 어렵다.
즉, 오직 코드를 통해서만 문서화하는 것은 포괄적인 UML 다이어그램을 사용할 때 일어나는 것과 기본적으로 동일한 문제를 일부 지니고 있다.
물론 팀 내에서 구두에 의한 의사소통이 활발하게 일어난다면 코드에 맥락과 지침을 제시할 수 있지만 그러한 의사소통은 일시적이고 국지적인 양상을 띤다. 그리고 개발자만 모델을 이해해야 하는 것은 아니다.

문서는 코드가 이미 잘 하고 있는 것을 하려고 해서는 안 된다. 코드는 이미 세부사항을 충족한다. 코드는 프로그램의 행위를 정확하게 규정한 명세에 해당한다.

다른 문서들은 의미를 설명하고, 대규모 구조에 통찰력을 주며, 핵심 요소에 집중할 필요가 있다.
글로 쓴 문서는 코드와 논의를 보완해야 한다.

• 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.

다이어그램을 손으로 그리면 일을 줄이는 것 말고도 딱딱하지 않고 임시적이라는 느낌을 준다는 이점도 있다. 이러한 특성은 일반적으로 우리가 모델에 관해 생각하는 바도 그러하기 때문에 의사소통에 도움이 된다.
팀의 철학에 따라 전체 설계 문서는 벽에 붙여둔 여러 장의 밑그림 만큼이나 간단할 수도 있고, 혹은 상당한 양이 될 수도 있다.

• 문서는 프로젝트 활동과 관련을 맺고 있어야 한다.
  이를 판단하는 가장 쉬운 방법은 문서가 UBIQUITOUS LANGUAGE와 상호작용하는지 살펴보는 것이다.
  프로젝트에서 쓰는 언어로 작성돼 있는가? 문서가 코드에 포함된 언어로 쓰여 있는가?

• UBIQUITOUS LANGUAGE와 그것이 어떻게 변화하는지에 주의를 기울여야 한다.
  설계 문서에 설명된 용어가 대화와 코드에 나타나지 않는다면 문서가 본연의 목적을 수행하지 못하고 있는셈이다.
  문서가 UBIQUITOUS LANGUAGE에 아무런 영향도 주지 못한다면 뭔가 잘못된 것이다.

문서는 이력으로 안전하게 보관해 둘 수도 있지만 유효한 상태로 혼란을 일으키고 프로젝트에 악영향을 줄 수도 있다. 그리고 문서가 중요한 역할을 수행하지 않는다면 순수한 의지와 자제력를 발판삼아 문서를 최신 상태로 유지하는 것은 노력의 낭비 일뿐이다.

UBIQUITOUS LANGUAGE를 바탕으로 작성된 요구사항 명세와 같은 다른 문서는 좀더 간결하고 덜 모호해진다.
도메인 모델이 업무와 가장 직접적인 관련이 있는 지식을 반영하게 되면 애플리케이션의 요구사항은 해당 모델 내에서 시나리오가 되고 UBIQUITOUS LANGUAGE는 MODEL-DRIVEN DESIGN과 직접적으로 연결돼 있다는 점에서 그러한 시나리오를 기술하는 데 사용될 수 있다.

결과적으로 명세는 더욱 간결하게 쓰여질 수 있는데, 이것은 모델 이면에 놓인 업무 지식을 명세에서 전달할 필요가 없기 때문이다.

문서를 최소한으로 유지하고 코드와 대화를 보완하는 데 집중함으로써 문서는 프로젝트와 연관된 상태로 유지할 수 있다.

실행 가능한 기반

잘 작성된 코드는 의미 전달에 매우 충실할 수 있지만 코드가 전달하는 메시지가 정확하다는 보장은 없다.
메서드 이름이 모호하거나 잘못된 방향으로 유도하거나, 또는 메서드 내부와 비교해서 이전 것일 수 있다.

이 같은 불일치를 제거하는 것은 선언적 설계와 같은 접근법에서 주로 강조하는 특징에 해당한다.
이러한 접근법에서는 프로그램 요소의 목적을 서술하는 것이 곧 프로그램 내의 실제 행위를 결정한다.

현재의 표준 기술을 활용해 코드의 행위, 의도, 메시지를 일치시키려면 훈련과 설계에 관한 어떤 특정한 사고방식이 필요하다.
의사소통을 효과적으로 하려면 코드는 요구사항을 작성하는 데 사용한 것과 동일한 언어이자 개발자가 다른 개발자와 이야기하거나 도메인 전문가와 이야기를 나눌 때 사용하는 것과 동일한 언어에 기반을 둬야한다.

설명을 위한 모델

이 책의 요점은 하나의 모델이 구현, 설계, 의사소통의 기초가 돼야 한다는 것이다. 이러한 각 목적에 각기 다른 모델을 갖추는 것은 바람직하지 않다.

모델은 도메인을 가르치는 도구로도 아주 유용할 수 있다.
설계를 주도하는 모델은 도메인을 바라보는 하나의 관점에 해당하지만 도메인의 일반 지식을 전달하기 위해 교육적인 도구로만 사용되어 다른 관점을 견지하는 것을 익히는 데 도움을 줄 수 있다.
이러한 목적으로 사람들은 소프트웨어 설계와는 무관한 다른 종류의 모델을 전달하는 그림이나 단어를 활용할 수 있다.

설명을 위한 모델에서는 특정 주제에 맞춰 훨씬 더 전달력이 높은 의사소통 방식을 마음껏 만들어낼 수 있다.
설명을 위한 모델이 꼭 객체 모델일 필요는 없으며, 오히려 그렇지 않을 때가 일반적으로 가장 좋다.

모델에 대한 다이어그램 + 특정 도메인에 대한 시각적인 자료와 함께 설명을 하면 좋다.