도메인 주도 설계 - 2. 의사소통과 언어 사용(UBIQUITOUS LANGUAGE)

본 내용은 에릭 에반스의 도메인 주도 설계를 공부하면서 제 나름대로 이해하기 쉽게 정리한 글입니다.

이해가 어려우시다면 댓글 부탁드립니다.

---

문제

공통 언어가 없는 프로젝트는...

1. 개발자가 도메인 전문가를 위해 자신들의 언어를 번역해줘야 함
2. 도메인 전문가도 개발자 간, 다른 도메인 전문가 간의 언어를 번역해줘야 함
3. 심지어 개발자 사이에서도 서로 번역해줘야함

이렇게 되면 일상적인 토론에서 쓰이는 용어가 코드에 녹아는 용어와 단절된다. 번역은 의사소통을 무디게 하고 지식 탐구는 빈약하게 만든다.

UBIQUITOUS LANGUAGE(보편 언어)

 프로젝트 팀원들 사이에 탄탄한 토대가 될 보편 언어가 필요하다. 도메인 모델이 이 보편 언어의 근간을 제공하고 소프트웨어 구현에 이르기까지 연결할 수 있다. 보편 언어는 개발자와 도메인 전문가 등 프로젝트 팀원들 사이에 적용되는 공통된 언어이다. 한 팀에서 특정 도메인 모델이 A와 B로 부를 수 있으면 안되고 둘 중 하나로 통일해서 불러야 한다는 의미이다.

 보편 언어는 개발자 사이에서 소프트웨어 결과물뿐만 아니라 업무와 기능을 기술할 때도 사용해야 한다. 하지만, 초기 도메인 모델은 이정도 수준까지 못미치는데 지식 탐구를 통해서 가능해진다. 

 보편 언어를 사용하다보면 모델의 취약점이 발견되는데 이 취약점이 해결되면 도메인 모델이 변화하게 되고 소프트웨어 코드상 클래스나 메서드등 바뀌게 될 것이다.

 

 정리하면 도메인 모델을 언어의 근간으로 사용해야 한다. 팀 내 모든 의사소통과 코드에서 보편언어를 끊임없이 적용하는데 전념해야 한다. 특히 말할 떄 동일한 보편 언어를 사용해야 한다.

UBIQUITOUS LANGUAGE(보편 언어)의 변화가 곧 모델의 변화라는 것을 인식해야 한다.

한 팀, 한 언어

개발자들이 만든 모델들은 도메인 전문가들도 이해가 가능해야 한다. 설계에는 도메인 전문가와 관련 없는 기술도 있지만 모델의 핵심은 도메인 전문가가 이해할 수 있어야 한다. 도메인 전문가와 개발자 사이에 언어적 분열이 일어나면 안 된다.

문서와 다이어그램

다이어그램은

1. 의사소통과 설명의 수단이며 브레인스토밍을 촉진한다. 대신, 다이어그램은 최소화(3~5개정도)됐을 때 가장 좋다.
2. 모든 객체 모델을 포괄하는 다이어그램은 의사소통과 설명이라는 목적을 달성하지 못하기 때문에 좋지 않다.
3. 모델이 나타내는 개념의 의미와 모델내 객체의 행위를 전달할 수 없는데 이 부분은 별도의 텍스트나 대화의 몫으로 남는다.
4. 보조적인 역할일뿐이다.

설계의 생생한 세부사항은 코드에 담긴다. 모델은 다이어그램이 아니라는 것을 명심해야 한다

 

문서는

1. 코드와 말을 보완하는 역할을 해야한다.
2. 코드가 이미 잘 하고 있는것을 하려고 해서는 안 된다. 
3. 유효한 상태를 유지하고 최신 내용을 담고 있어야 한다.
4. UBIQUITOUS LANGUAGE(보편언어)와 상호작용 해야한다.

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