Ubiquitous Language 적용 전 후

DDD를 이해하는데 여러가지 개념이 있지만 그중에서도 제일 어려운 것 중의 하나가 Ubiquitous Language(UL) 다.
그런데 지금 참고하고 있는 IDDD 책에서도 'DDD의 가장 강력한 요소중 하나'라고 표현하고 있다.
번역하면 '보편언어' 정도 되는가 본데 더 이해하기 어렵다. 무엇이 보편적이라는것인지...
그리고 수많은 사이트에서도 교집합 또는 접점이되는 비슷한 그림으로 줄기차게 설명하고 있지만 여전히 이해되지 않기는 마찬가지다. 그렇게 중요하다고 강조하는데 이해도 잘 안되고, 프로젝트 현장에서는 더더욱 뭐가 UL이고 어떻게 적용한다는것인지..., 그러던 차에 이책의 아래 예를 보고 많이 느꼈다.


'간호사가 독감 백신을 표준 용량으로 환자에게 투여한다' 라는 상황을 표현하면 어떨까?

 

//1. 그냥 코딩
patient.setShotType(ShotType.TYPE_FLUE);
patient.setDose(dose); //dose : 복용량, 투여량
patient.setNurse(nurse);

 

//2. 환자에게 독감 주사를 놓는다
patient.giveFluShot();

 

//3. 간호사가 환자에게 정량의 독랍 백신을 투여한다
Vaccine vaccine = vaccines.standardAdultFluDose();
nurse.administerFluVaccine(patient, vaccine); //administer : 약을 투여하다

 

어떠한가? 
뭔가 달라지는게 느껴지는가?

업무 전문가와 대화를 많이해서 목표에 점점 다가가는 느낌이지 않는가?

그냥 주어진 상황에 코딩하는것과 달리 좀 더 고민의 흔적도 느껴지고...
그리고 무엇보다 어떤 것이 비즈니스에 더 잘 맞는가?

 

 

• UL은 팀 내에 공유된 언어다
• 도메인 전문가와 개발자 간에 같이 공유된다
• 해당 프로젝트에 참여하는 모든 사람간에 공유된다
• 공개적인 토론이나 기존 문서의 참고나 결국 수면위로 드러날 비즈니스 지식 등을 비롯해 표준, 사전, 동의어 사전 등을 참조하는 과정을 통해 UL만들어짐
• 용어집을 만들라
• 소프트웨어 모델 자체에 특정 핵심 비즈니스 도메인의 개념과 용어를 포착하는데 사용되는 팀의 패턴이다
• 유비쿼터스는 '만연하다', '어디에서나 발견된다' 는 의미, 즉 팀원간에 사용되고 팀이 개발하는 하나의 도메인 모델로 발현
• 엔터프라이즈 전체의 전사적인, 혹은 세계적이고 보편적인 도메인 언어를 설명할려는 의도는 아니다
• 바운디드 컨텍스트 당 하나의 UL
• UL는 바운디드 컨텍스트를 격리 시키고 그 안에서 프로젝트의 개발 업무를 수행하는 팀 내부에서만 유비쿼터스하다

UL에 대해 여러가지 측면으로 설명하고 있는데, 결국 UL의 중요한것은 도메인 전문가, 즉 업무 전문가, 현업과 가깝게 의사소통하면서 함께 고민하고 용어 등을 정리해 가는 것이다. 단순히 메타, 용어집, 요구사항 정의서 등 산출물 몇 개 만든다고 되는것은 아니지만 그러한 노력들이 모여 고객사의 현업/IT 수행사의 분석설계자/개발자까지 공유/공감되는 상태를 말하는 것이라 생각한다. 이게 잘 와닿지 않았던 이유는 우리는 현장에서 고객 얼굴도 잘 보지 못하고, 산출물 위주로 간신히 검토 정도하는 상황이라 그랬는가 보다.

그럼 어떻게 시작할 수 있을까?
개발팀에 업무 전문가인 현업도 초대하고 가능하면 상주하면서 개발자와 함께 의사소통하고 함께 만들어 갈 수 있는 방법이 ...

그 출발은 아마도 서비스정의 워크샾이라 생각한다. 

 - Implementing Domain-Driven Design 도메인 주도 설계 구현, 반 버논
   1장 DDD를 시작하며 p.72 ~ p.78 의 내용 발췌 + 첨언