DDD - 비즈니스 지식 찾기, 유비쿼터스 언어
이 포스트에서는 아래 내용에 대해 알아본다.
- 유비쿼터스 언어
- 유비쿼터스 언어는 효과적인 커뮤니테이션과 지식 공유를 위한 DDD 실무임
- DDD 진행 시 반드시 포함해야 하는 개념
- 프로젝트와 관계된 다양한 이해관계자 사이에서 해당 비즈니스 도메인의 이해를 돕기 위해 사용됨
- 유비쿼터스 언어를 개발하고, 효율적으로 활용하기 위한 방법
이 포스트에서는 비즈니스 도메인 분석 주제에 대해 다루지만 좀 더 깊이 있게 하위 도메인 내부에서 일어나는 일, 즉 비즈니스 기능과 로직에 초점을 맞춘다.
효과적인 커뮤니케이션과 지식 공유를 위한 DDD 도구인 유비쿼터스 언어에 대해 알아본 후, 유비쿼터스 언어를 통해 비즈니스 도메인의 복잡성에 대해 알아본다.
이후 비즈니스 로직을 소프트웨어 모델로 만들고 구현하는데 이를 활용해본다.
목차
1. 비즈니스 문제
비즈니스 문제는 비즈니스 도메인과 하위 도메인의 모든 수준에서 발생할 수 있다.
하위 도메인은 세분화된 문제 도메인으로, 특정 비즈니스 기능에 대한 솔루션을 제공하는 것이 목적이다.
예) 지식 관리 하위 도메인은 정보를 저장하고 추출하는 프로세스 제공 / 회계 하위 도메인은 기업의 자금을 관리하는 솔루션 제공
2. 도메인 지식 찾기
효과적인 소프트웨어 솔루션을 설계하려면 기본적인 비즈니스 도메인 지식이 있어야 하는데 이런 지식은 도메인 전문가의 몫이다.
개발자는 도메인 전문가가 될 필요도 없고 될 수도 없다.
결국 도메인 전문가를 이해하고 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이 중요하다.
효과적인 소프트웨어는 도메인 전문가가 문제를 생각하는 방식인 멘탈 모델을 모방해야 한다.
비즈니스 문제와 요구 사항 이면에 있는 이유에 대한 이해가 없다면 솔루션은 비즈니스 요구사항을 소스 코드로 번역한 것에 불과하다.
소프트웨어 프로젝트의 성공은 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에 달렸다.
그러기 위해선 도메인 전문가와 소프트웨어 엔지니어 간에 지식 공유를 할 때 효과적인 커뮤니케이션이 필요하다.
3. 커뮤니케이션
프로젝트와 연관된 모든 것에 대한 합의와 일치는 프로젝트 성공의 필수 요소이다.
- 해결하려는 문제에 대하여 모든 이해관계자가 동의하는지?
- 개발하고 있는 솔루션의 요구사항 중 서로 충돌하는 가정이 있지는 않은지?
효과적인 커뮤니케이션은 지식 공유와 프로젝트 성공에 필수적이다.
전형적인 소프트웨어 개발 생애주기에서 소프트웨어 프로젝트에서의 지식 흐름은 아래와 같다.
- 도메인 전문가 → 소프트웨어 분석가 → (소프트웨어 요구사항 문서) → 개발자 → (코드)
위와 같은 경우 도메인 지식은 분석 모델로 알려진 엔지니어 친화적인 형태로 “변환” 되는데, 이 경우 분석 모델은 도메인 지식 이면에 있는 비즈니스 도메인에 기반하기보다는 시스템 요구 사항을 설명한 것에 지나지 않는다.
모든 변환은 정보를 잃게 만드므로 이런 식의 중재는 지식을 공유하는데 악영향을 미친다.
비즈니스 문제 해결에 중요한 도메인 지식은 소프트웨어 엔지니어에게 전달되는 과정에서 손실된다.
이런 개발 과정은 도메인 지식을 종종 왜곡된 상태로 전달되게 한다.
이런 문제를 해결하기 위해 DDD 는 도메인 전문가가 소프트웨어 엔지니어에게 지식을 전달하기 위한 방법으로 유비쿼터스 언어를 제안한다.
4. 유비쿼터스 언어
유비쿼터스 언어는 이해관계자들이 효과적으로 소통하기 위해 변환에 의존하지 않고 같은 언어를 사용하는 것이다.
전통적인 소프트웨어 개발 생애주기에서의 변환은 아래와 같다.
- 도메인 지식이 분석 모델로
- 분석 모델이 요구사항으로
- 요구사항이 시스템 설계로
- 시스템 설계가 소스 코드로
반면 DDD 에서는 이같은 도메인 지식을 계속해서 변환하는 대신, 비즈니스 도메인을 설명하기 위한 단일화된 언어 체계를 사용하는데 이것이 바로 유비쿼터스 언어이다.
즉, 모든 이해 관계자들이 비즈니스 도메인을 설명할 때 유비쿼터스 언어를 사용한다.
5. 비즈니스 언어
유비쿼터스 언어는 비즈니스 언어이기 때문에 기술 용어는 빼고 비즈니스 도메인에 관련된 용어로만 구성해야 한다.
예) 비즈니스 도메인 전문가에세 싱글턴이나 추상 팩터리같은 것을 가리키는 것은 목적이 아님
유비쿼터스 언어는 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현해야 한다.
유비쿼터스 언어는 반드시 정확하고 일관성있어야 하며, 오직 하나의 의미만을 가져야 한다.
예를 들어 ‘정책(policy)’ 라는 모호한 용어 대신 ‘규제 규칙(regulatory rule)’, ‘보험 계약(insurance contract)’ 이라는 용어를 사용하여 명확한 모델을 만들어야 한다.
유비쿼터스 언어에서 두 용어는 서로 바꿔서 사용할 수 없다.
예를 들어 ‘사용자’ 라는 용어를 도메인 전문가의 언어로 설명하면 ‘사용자’, ‘방문자’, ‘관리자’, ‘계정’ 등 다른 의미들로 사용될 수 있다.
이런 동의어는 대부분 서로 다른 개념을 가진다.
‘방문자’ 와 ‘계정’은 기술적으로는 시스템의 사용자를 가리키지만 ‘방문자’ 데이터는 주로 분석 목적으로 사용되는 반면, ‘계정’ 은 시스템의 기능을 실제로 사용한다.
특정 컨텍스트 안에서 각각의 용어를 사용하는 것이 바람직하다.
6. 비즈니스 도메인 모델
여기서는 모델링 관점에서 유비쿼터스 언어를 살펴본다.
6.1. 모델
모델은 사물이나 현상에서 의도한 관점만 강조하고 다른 측면은 무시하여 간략하게 표현한 것이다.
예를 들어 길 안내 지도, 세계 지도, 지하철 노선도 모두 세부적인 모든 것을 표현하지는 않는다.
대신 각 지도는 특정 목적을 지원하는데 충분한 자료만 담고 있다.
6.2. 효과적인 모델링
모든 모델에는 목적이 있고, 효과적인 모델은 그 목적을 달성하는데 필요한 세부사항만 포함한다.
예를 들어 세계 짖도에는 지하철 노선 정보는 없다.
유용한 모델은 실세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 한다.
모델은 본질적으로 추상화의 결과이다.
추상화 개념은 불필요한 상세 정보를 생략하여 복잡한 문제를 다룰 수 있게 하고, 문제를 해결하는데 필요한 정보만 남게 한다.
추상화의 목적은 모호함이 아니라 절대적으로 정확할 수 있는 새로운 의미론적 수준을 만드는 것이다.
6.3. 비즈니스 도메인 모델링
모델은 비즈니스가 기능을 어떻게 구현하느냐에 대한 도메인 전문가의 사고 프로세스인 멘탈 모델을 포착해야 하며, 비즈니스 엔티티와 그것의 행동, 인과 관계, 불변성 등을 반영해야 한다.
유비쿼터스 언어는 도메인의 모든 가능한 상세 정보를 포함하는 것이 아니다.
모델은 필요한 시스템을 구현하는데 필요한 만큼의 비즈니스 도메인 괌점을 포함하면 된다.
엔지니어링팀과 도메인 전문가의 효과적인 커뮤니케이션을 필수이며, 비즈니스 도메인의 이해를 확인할 신뢰성 있는 유일한 방법은 도메인 전문가가 이해할 수 있는 비즈니스 언어로 대화하는 것이다.
6.4. 지속적 노력
유비쿼터스 언어를 정형화하려면 언어의 소유자인 도메인 전문가와의 상호 작용이 필요하다.
오직 실제 도메인 전문가와의 상호 작용만이 비즈니스 도메인에 대한 부정확함이나 잘못된 가정, 이해 오류를 발견할 수 있다.
요구 사항, 테스트, 문서화, 소스 코드 등 프로젝트 전반에 걸쳐 유비쿼터스 언어를 지속해서 사용해야 지식 공유가 확산될 수 있다.
유비쿼터스 언어는 지속해서 검증하고 발전시켜야 한다.
6.5. 도구
유비쿼터스 언어를 수집하고 관리하는 과정을 돕는 도구와 기술이 있다.
- 용어집
- 예를 들어 위키는 유비쿼터스 언어를 수집하고 관리하는 용어집(glossary)으로 사용될 수 있음
- 용어집은 비즈니스 도메인의 용어에 대한 정보를 얻을 수 있는 거점 역할을 하므로 새로운 팀원이 쉽게 적응할 수 있게 해줌
- 유비쿼터스 언어가 변경되면 한 사람이 담당해서 수정하는 것이 아니라 모든 팀원이 수정할 수 있도록 해야함
- 거킨 언어(Gherkin language)
- 용어집은 엔티티의 이름, 역할 등 명사에만 효과적임
- 명사도 중요하지만 행동을 포착하는 것도 중요함
- 행동은 단순히 명사와 관련된 동사의 목록이 아니라 규칙, 가정, 불변성을 가진 실제 비즈니스 로직임
- 이런 개념은 용어집으로 문서화하기가 어려움
- 따라서 용어집은 유스케이스 또는 거킨 테스트 처럼 행동을 포착하는데 적합한 다른 도구와 함께 사용하는 것이 좋음
- 거킨 언어로 작성된 자동화 테스트는 유비쿼터스 언어를 포착하기에 좋은 언어일 뿐 아니라 도메인 전문가와 소프트웨어 엔지니어의 간극을 메우는 보조 도구의 역할을 함
- 도메인 전문가는 테스트를 읽고 시스템의 기대 행동을 검증할 수 있
거킨 언어로 작성된 테스트 예시
Scenario: 에이전트에게 새로운 지원 케이스에 대해 알린다.
Given: assu 는 다음 내용을 담은 새로운 지원 케이스를 제출한다.
"""
나는 AWS WAF 를 설정하는데 도움이 필요하다.
"""
When: 티켓이 silby 에게 할당된다.
Then: 에이전트는 새로운 티켓에 대해 알림을 받는다.
- NDepend
- 유비쿼터스 용어의 사용을 검증할 수 있는 정적 코드 분석 도구
6.6. 도전 과제
도메인 지식을 수집하는 신뢰할 만한 유일한 방법은 도메인 전문가와 대화하는 것이다.
중요한 지식은 문서화되거나 코드로 작성되지 않고 도메인 전문가의 정신에만 존재할 가능성이 있으므로 이에 접근하는 유일한 방법을 질문하는 것이다.
정리하며..
- DDD 의 유비쿼터스 언어는 도메인 전문가와 소프트웨어 엔지니어의 지식 간극을 메워주는 효과적인 도구임
- 효과적인 소통을 위해서는 유비쿼터스 언어에서 반드시 모호성과 암묵적 가정을 제거해야 함
- 언어의 모든 용어는 일관성이 있어야 하고, 동의어가 없어야 함
- 유비쿼터스 언어는 지속적으로 육성되어야 함
- 위키 기반 용어집과 거킨 테스트 같은 도구는 유비쿼터스 언어를 문서화하고 유지보수하는 과정을 상당히 쉽게 해줌
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 블라드 코노노프 저자의 도메인 주도 설계 첫걸음을 기반으로 스터디하며 정리한 내용들입니다.
