1. 도메인 주도 설계
Domain-Driven Design
2장
의사소통과 언어 사용
아꿈사
이영권
whiletrue0222@gmail.com

2. 목차
2장 의사소통과 언어 사용 p23
• UBIQUITOUS LANGUAGE (보편 언어) p24
• 크게 소리내어 모델링하기 p31
• 한 팀, 한 언어 p32
• 문서와 다이어그램 p35
o 글로 쓴 설계 문서 p37
o 실행 가능한 기반 p40
• 설명을 위한 모델 p41

3. 의사소통과 언어 사용
도메인 모델은 소프트웨어 프로젝트를
위한 공통언어의 핵심이 될 수 있다.
• 축적된 개념의 모음
• 용어와 관계로 표현되며 의미체계를 제공
• 코드와 연계하는데 연결고리 역할을 한다.
모델기반 의사소통은 UML상의 다이어그램으로 한정돼면 안 된
다.
• 모든 의사소통 수단에 스며들 필요가 있다.

4. UBIQUITOUS LANGUAGE (보편 언어)
유연하고 풍부한 지식이 담긴 설계를 만들려면
다용도로 사용할 수 있는
팀의 공유 언어(UBIQUITOUS LANGUAGE)가
필요.
공유 언어에 대한 활발한 실험이 필요하지만
대부분의 안 한다.

5. UBIQUITOUS LANGUAGE (보편 언어)
UBIQUITOUS LANGUAGE를 사용하지 않는다면..
• 도메인 전문가와 개발자는 서로 사용하는 전문 용어를 알지
못한다.
• 개발자가 도메인 전문가가 이해 못하는 방식으로 추상화 할
수도 있다.
• 공통 언어가 없다면 서로 간의 언어를 번역해줘야 한다.
이 마저도 모호하다!!

6. UBIQUITOUS LANGUAGE (보편 언어)
UBIQUITOUS LANGUAGE를 구성하는 어휘
• 클래스와 주요연산
• 규칙을 토론하기 위한 용어
• 높은 수준의 구성 원칙 용어 (14장과 16장 CONTEXT MAP)
• 도메인 모델에 적용하는 패턴 이름
모델 기반 언어를 다방면에서 사용해야한다.
• 업무와 기능을 기술할 때
• 요구사항, 개발 계획, 기능에 관해 의사소통할 때

7. UBIQUITOUS LANGUAGE (보편 언어)
처음 도입시에는 언어가 역할을 다하지 못할 것이다.
• 의미적 풍부함 결여
• 실제적인 특징 누락
• 개념의 불분명함
계속 실험하고 끊임없이 적용하라.
• 의사소통과 코드에 사용
• 대안모델을 반영하는 표현을 시도
일단은...
계속 언어를 사용하고 발전 시키고
언어의 변화가 모델의 변화를 인식하라.

8. 크게 소리내어 모델링하기
인간은 구어에 재능을 지니고 있으므로
다른 형태의 의사소통(문서 등등?)과 말하기를
분리하면 손실

9. 크게 소리내어 모델링하기
대화시 도메인 모델의 언어를 사용하지 않을 때 문제
• 대화가 간결하지 못함.
• 모호해지며 기술적으로 된다.

10. 크게 소리내어 모델링하기
시스템에 관해 이야기를 주고 받을 때
모델을 사용하여
인간의 언어적 재능을 모델을 개발하는 데 활용하라

11. 한 팀, 한 언어
종종 기술 담당자들이 업무전문가에게
도메인 모델을 보여 줄 필요가 없다고 생각한다.
• “업무 전문가들에게는 너무 너무 추상적이라서요.”
• “객체를 이해 못해요.”
• “업무 전문가들이 쓰는 용어로 된 요구사항을 만들어야 해요.”
여러 이유로 팀에 두가지 언어가 존재하게 된다.

12. 한 팀, 한 언어
도메인 전문가도 이해 못하는 모델은 문제가 있다.
같은 언어를 사용해야 서로간의 잘못된 점을 발견할 수 있다.
• 잘못 알고 있던 부분
• 이해가 부족한 부분
그러므로 언어의 분열이 일어나면 안된다.

13. 한 팀, 한 언어
때로는 여러 언어가 필요할 때도 있다.
서로간의 이해 수준을 넘는 용어는
UBIQUITOUS LANGUAGE의 확장 영역.

14. 문서와 다이어그램
문서로서의 UML다이어그램
장점
• UML다이어그램은 정보를 파악하는데 도움
• 간결한 UML다이어그램으로 논의의 구심점 역할
단점
• 개념적 정의와 객체의 행위를 전해주지는 못한다.
• UML로 전체 모델을 표현하려고 할 때 문제가 발생한다.
o 너무 복잡해진다.

15. 문서와 다이어그램
다이어그램이 문서가 아니다.
• 설계의 세부사항은 코드로 담아라
• 간결한 다이어그램이 그려진 텍스트 문서를 작성해라
모델은 다이어그램이 아니다.
• 다이어그램은 모델을 전달하고 설명하는 데 있다.

16. 글로 쓴 설계 문서
구두의 의한 의사소통이 좋긴하지만
글로 쓴 문서로 안정과 공유가 필요
• 문서는 코드와 말을 보완하는 역할을 해야한다.
o 설계문서로서의 코드에는 한계가 있다.
o 코드가 이미 잘 하고 있는 것을 하면 안 된다.
• 문서는 유효한 상태를 유지하고 최신 내용을 담고 있어야 한
다.
o UBIQUTOUS LANGUAGE로 작성돼야 한다.
o 문서를 최소한으로 유지 코드와 대화를 보완하는 데 집중

17. 설명을 위한 모델
구현, 설계, 의사소통에 각기 다른 모델을
갖추는 것은 바람직하지 않다.
하지만..
모델은 도메인을 가르치는 도구로 유용하며
설계 모델과는 무관한 다른 관점의 모델이 도움이 될 수 있다.
설명을 위한 모델은 객체 모델일 필요는 없으며,
그렇지 않을 때 일반적으로 가장 좋다.

18. 설명을 위한 모델
설계를 위한 모델

19. 설명을 위한 모델
설명을 위한 모델

20. 감사합니다.