유비쿼터스 언어(UBIQUITOUS LANGUAGE)
프로젝트를 진행하다보면 다음과 같은 상황을 겪어볼 수 있다.
첫번째 - 회원 관련
사용자A : 신규 회원을 등록하겠습니다.
사용자B : 신규 회원을 추가하겠습니다.
사용자가 말하는 등록과 추가는 무슨 의미일까?
모두 신규 회원이 가입되었다는 의미로 사용하는 걸까?
두번째 - 상품 관련
MD1 : 노트북 상품을 추가하겠습니다.
MD2 : 노트북 제품을 등록하겠습니다.
사용자가 말하는 상품과 제품은 같은 의미로 사용하는 걸까?
추가와 등록은 이전 회원에 비해 헷갈린다. 단순히 수량을 추가하는 걸까? 새롭게 상품&제품을 등록한다는 걸까?
이렇듯 같은 팀내에서 도메인에 대한 용어가 제각각인 경우를 겪어본 적이 있을 거다. (혹은 용어가 같지만 다른 의미로 사용된 경우)
이런 차이로 같은 도메인을 서로 다르게 바라보고 각자 이해하게 되며, 나중에는 문제로 발전하는 상황이 올 수 있다. (개발자와 비개발자의 차이는 더욱 끔찍하다)
이를 해결하려면 어떻게 해야할까? 그에 관련해서 유비쿼터스 언어를 언급하려고 한다.
유비쿼터스 언어
도메인에서 사용하는 용어를 코드에 반영하지 않으면, 개발자는 코드의 의미를 해석해야 하는 부담을 가지게 된다.
유비쿼터스 언어는 이런 부담을 줄여주고, 프로젝트 관계자(개발자와 비개발자)가 모두 이해하는 공통된 용어를 사용할 수 있도록 한다.
유비쿼터스 - 언제, 어디서나 컴퓨터 네트워크에 접속할 수 있는 환경을 뜻함.
* 번역에 따라 유비쿼터스 언어를 보편적 언어라고 부르기도 한다.
용어 사전 관리
모두가 이해하는 유비쿼터스 언어는 단순히 명사뿐만 아니라 동사까지 용어 사전으로 관리해야한다.
관리 방법은 JIRA, 파일 문서 등 다양하며, 편안한 방식으로 관리하면 된다.
개발자만 있는 경우 도메인마다 README.md로 관리하는 방법도 있다.
효과적인 모델링
- 사용자와 개발자는 동일한 언어로 이야기하는가? (용어에 대해 같은 생각을 하는가?)
- 해당 언어가 애플리케이션에서 수행해야 할 내용에 관한 논의를 이끌어갈 만큼 풍성한가? (표현력이 충분한가?)
- 표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음에 새로운 아이디어를 다이어그램과 코드에 적용한다.
* 모델링은 ERD, 다이어그램, 유스케이스 같은 것만 모델링이 아니다.글 문장(끄적인 낙서도 포함)도 모델링이 될 수 있다. 이를 보고 이해하는지가 중요하다.
한 팀, 한 언어
사업팀에게 개발자 측면의 객체지향적으로 설명하면 사업팀은 이해할 수 없다.
사업자도 이해할 수 있는 용어로 소통하고 코드로 구현해야한다.
- 잘못된 용어 : 인터페이스, 외부 클라이언트, 전략 패턴
- 올바른 용어 : 정책, 페이먼트 에이전시, 비속어 목록
참고 자료
DDD 세레나데, NEXTSTEP
용어 사전, 모델링 예제