[DDD 첫걸음] 1-2. 전략적 설계 - 도메인 지식 찾아내기.

 

운영환경에 배포되는 것은 도메인 전문가의 지식이 아니라 개발자의 이해 혹은 오해다.
- 알베르토 브랜돌리니

 

 

이번 장에서는 효과적인 커뮤니케이션과 지식 공유를 위한 도메인 주도 설계 도구인 유비쿼터스 언어를 배우고, 유비쿼터스 언어를 통해서 비즈니스 도메인의 복잡성을 배우며 책 후반부에서 비즈니스 로직을 소프트웨어 모델로 만들고 구현하는 데 이를 활용한다.

 

비즈니스 문제

• 우리가 개발하는 소프트웨어 시스템은 비즈니스 문제를 해결하는 솔루션이다.
• 비즈니스 도메인의 컨텍스트에서 '문제'의 의미는 광범위하다.
  (워크플로와 프로세스 최적화, 수작업 최소화, 자원관리, 의사결정 지원, 데이터 관리 등과 관련한 과제일 수 있음.)
• 기업의 목표는 고객의 문제를 해결하는 솔루션을 제공하는 것이다. 

 

도메인 지식 찾아내기

• 효과적인 소프트웨어 솔루션을 설계하려면 적어도 기본적인 비즈니스 도메인 지식이 있어야함.
• 지식은 도메인 전문가의 몫.
• 효과적인 소프트웨어는 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야함.
  (비즈니스 문제와 요구사항 이면에 있는 이유에 대한 이해가 없다면 요구사항을 소스코드로 번역한 것에 불과함.)
• 알베르토 브랜돌리니는 "소프트웨어 개발은 배우는 과정이고, 작동하는 코드는 그 부산물이다" 라고 하였다.
• 소프트웨어 프로젝트의 성공은 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식공유에 달렸다!
• 결론적으로는 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식공유에는 효과적인 커뮤니케이션이 필요.

 

커뮤니케이션

• 거의 모든 소프트웨어 프로젝트에는 다양한 역할의 이해관계자의 협업이 필요.
• 프로젝트와 연관된 모든 것에 대한 합의와 일치는 프로젝트의 성공에 필수적.
• 소프트웨어 프로젝트에서 실패하는 이유에 대한 연구에서 효과적인 커뮤니케이션이 지식 공유와 프로젝트 성공에 필수라는 것을 밝혀냈다.
• 일반적으로 "도메인 전문가 -> 소프트웨어 분석가 -> 소프트웨어 요구사항 -> 개발자 -> 프로그램 개발" 의 흐름으로 흘러가며, 각 과정에서 도메인 지식은 분석 모델(엔지니어 친화적인 형태)로 변환된다.
• 이 과정에서 비즈니스 문제 해결에 중요한 도메인 지식은 소프트웨어 엔지니어에게 전달되는 과정에서 손실된다.
• 이와 같은 문제 해결을 위해 DDD에서는 도메인 전문가가 소프트웨어 엔지니어에게 지식을 전달하기 위해 유비쿼터스 언어를 제안함.
  
  

유비쿼터스 언어란?

• 참가자들이 효과적으로 소통하기 위해 변환에 의존하지 말고 같은 언어를 사용하는 것.
• 일반적인 SW 개발 사이클 : 도메인 지식 -> 분석모델 -> 요구사항 -> 시스템설계 -> 소스코드
• DDD에서는 이같은 도메인 지식을 변환하지말고 비즈니스 도메인을 설명하기 위한 단일화된 언어체계를 세우고자 하였다. 
  이것이 유비쿼터스 언어이다.
• 도메인 전문가는 유비쿼터스 언어를 사용해 비즈니스 도메인을 추론하는 데에 편안함을 느껴야한다.
• 유비쿼터스 언어의 지속적인 사용이 모든 프로젝트 참가자의 공통된 이해를 이끌어 낼 수 있음.

 

비즈니스 언어 ( 유비쿼터스 언어의 관점 1 )

• 유비쿼터스 언어는 비즈니스 언어라는 점을 잊지말자.
  (기술용어는 빼고 비즈니스 도메인에 관련된 용어로만 구성해야함.)
• 예시)
  • 광고 캠페인은 다양한 창의적인 자료를 전시할 수 있다. (O)
    광고의 iFrame은 HTML파일을 표시 한다. (X)
  • 캠페인은 최소한 하나의 광고 할당이 활성화되어야 게시된다. (O)
    캠페인은 '활성-할당(active-placement)' 테이블에 하나의 연관 레코드가 있어야 게시된다.
• 일관성
  • 유비쿼터스 언어는 반드시 정확하고 일관성이 있어야함.
  • 가정할 필요가 없어야하고 도메인의 로직을 명료하게 표현해야 함.
    예시) 우버 앱에서 '사용자'라는 용어는 다양하게 해석될 수 있음.

 

비즈니스 도메인 모델 ( 유비쿼터스 언어의 관점 2 )

모델이란 무엇인가?

 

모델링 관점에서의 유비쿼터스 언어를 살펴본다.

 

 

모델이란 사물이나 현상에서 의도한 관점만 강조하고 다른 측면은 무시하여 간략히 표현한 것이다.
즉, 특정 용도를 마음에 둔 추상화의 결과다.
- 레베카 워프스-브록

 

 

• 효과적인 모델링
  - 효과적인 모델은 그 목적은 달성하는 데 필요한 세부사항만 포함.
  - 유용한 모델은 실세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공한다.
  - 모델은 본질적으로 추상화의 결과다.

 

 

추상화의 목적은 모호함이 아니라 절대적으로 정확할 수 있는 새로운 의미론적 수준을 만드는 것.
- Edsger W. Dijkstra -

• 비즈니스 도메인 모델링
  - 유비쿼터스 언어를 발전시키는 것은 비즈니스 도메인 모델을 구축하는 것.
  - 유비쿼터스 언어는 도메인의 모든 상세 정보를 포함하는게 아니다!!
  - 앞서 이야기했듯 특정 문제를 해결하는 데 필요한 만큼의 비즈니스 도메인 관점을 포함하면 됨.
  - 도메인이 복잡할 수록, 코드로 구현하기는 어려워지고, 도메인의 이해를 확인할 신뢰성 있는 유일한 방법은 도메인 전문가가 이해할 수 있는 언어로 대화하는 것임.
  
  

 

• 지속적인 노력
  - 유비쿼터스 언어를 정형화하려면 언어의 소유자인 도메인 전문가와의 상호작용이 필요.
  - 유비쿼터스 언어를 지속적으로 사용해서 지식 공유를 확산, 도메인에 대한 공유된 이해를 강화해야함.
  - 요구사항, 테스트, 문서화, 심지어 소스코드 자체 등 프로젝트 전반에 이 언어를 지속적으로 사용해야함.
  - 유비쿼터스 언어는 지속적으로 검증하고 발전시켜 나가야함.
  
  
  

 

• 도구
  - 용어집, 거킨언어,  등의 도구를 활용할 수 있음
  - 하지만 일상적인 상호작용에서 실제로 유비쿼터스 언어를 사용하는 것이 가장 중요.
  - 언어의 문서화가 언어를 사용하는 것을 대체할 수 없을 것. 결국 개인의 상호작용이 우선이다.
  
  

 

 

• 도전과제
  - 도메인 지식을 수집하는 신뢰할 만한 유일한 방법은 도메인 전문가와 대화하는 것.
  - 대부분의 지식은 암묵지. 따라서 질문하자!
  - 이해관계자들 사이에서 비즈니스 도메인을 효과적으로 반영하지 못하는 언어가 있을 수 있음. (DB 테이블명과 같은)
  - 이때 인내심을 가지고 올바른 언어를 사용하고자 해야함.
  - 영어권이 아니라면 비즈니스 도메인 엔티티의 이름은 영어로하자.

 

 

P.S. 정리를 하면서 느낀점은, 직접 프로젝트 내에서  도메인 전문가와의 대화를 통해 비즈니스 도메인을 이해해보고, 유비쿼터스 언어를 확립해 나가는 것을 직접 경험하는 것이 필요하다는 생각이 든다.