Ch1. 비즈니스 도메인 분석하기
도메인 주도 설계 수업 시간에 이 내용을 가르치면 학생들이 “우리가 이것을 알아야 하나요?”라고 이야기한다.
정답은 “그렇다”이다.
효과적인 솔루션을 설계하고 구축하기 위해서는 그것의 바탕이 되는 문제를 이해해야 한다.
[비즈니스 도메인이란?]
비즈니스 도메인이란 회사가 고객에게 제공하는 서비스를 말한다.
예를 들면
- 패덱스는 배송 서비스를 제공한다.
- 스타벅스는 커피로 가장 잘 알려져 있다.
- 월마트는 가장 널리 알려진 소매업체 중 하나다.
기업은 여러 비즈니스 도메인을 운영할 수 있다.
예를 들어 아마존은 소매와 클라우드 서비스를 모두 제공한다.
우버는 차량 공유 회사이면서 음식 배달 및 자전거 공유 서비스도 제공한다.
회사는 비즈니스 도메인을 자주 변경할 수도 있다.
[하위 도메인이란?]
비즈니스 도메인의 목표를 달성하기 위해서는 기업은 여러 가지 **하위 도메인(subdomain)**을 운영해야 한다.
하위 도메인은 비즈니스 활동의 세분화된 영역이다.
모든 회사의 하위 도메인은 고객에게 제공하는 서비스 단위로 비즈니스 도메인을 만든다.
하나의 하위 도메인으로는 회사가 성공하기 어렵다.
하위 도메인은 전체 시스템에서 하나의 구성요소일 뿐이다.
각각의 하위 도메인은 회사의 비즈니스 도메인에서 목표를 달성하기 위해 서로 상호작용해야 한다.
예를 들어 스타벅스는 커피를 만드는 일 외에 좋은 위치의 부동산을 구매하거나 임대하고, 직원을 고용하고, 재정을 관리해야 한다.
이러한 하위 도메인 중 어느 것도 자체적으로 수익을 낼 수는 없다.
하위 도메인의 유형
소프트웨어 시스템이 다양한 아키텍처 구성요소(데이터베이스, 프론트엔드, 백엔드, 기타 구성요소)로 이뤄진 것처럼, 하위 도메인은 서로 다른 전략적 비즈니스 가치를 가진다.
도메인 주도 설계에서 하위 도메인은 핵심, 일반, 지원의 세 가지 유형으로 구분된다.
핵심 하위 도메인
핵심 하위 도메인(**core subdomain)**은 회사가 경쟁업체와 다르게 수행하고 있는 것을 말한다.
가령 새로운 제품이나 서비스를 발명하거나 기존 프로세스를 최적화하여 비용을 줄이는 것이 그렇다.
우버의 경우, 처음에는 승차 공유 서비스를 제공했다.
경쟁업체가 그것을 따라잡으면 우버는 그에 대응해 핵심 비즈니스를 최적화하고 발전시킬 방법을 찾았다.
예를 들어, 같은 방향으로 향하는 손님을 매칭해서 비용을 절감할 수 있었다.
우버의 핵심 하위 도메인은 수익에 영향을 미친다. 우버는 이렇게 경쟁사로부터 차별화했다.
고객에게 더 좋은 서비스를 제공하고 수익성을 극대화하는 전략이다.
다른 예로 구글의 검색 알고리즘을 생각해보자.
구글의 광고 플랫폼이 구글 수익의 대부분을 차지한다.
구글 애즈(Google Ads)는 하위 도메인이 아니라, 하위 도메인이 있는 별도의 비즈니스 도메인이다.
그럼 구글 검색과 알고리즘은 어떤가?
구글 검색 엔진은 유료 서비스는 아니지만, 구글 애즈를 위한 가장 큰 플랫폼이다.
알고리즘에 버그가 생기면 광고 비즈니스 수익에 큰 타격을 주기 때문에 알고리즘이 핵심 알고리즘이 된다.
복잡성
구현하기 쉬운 핵심 하위 도메인은 일시적인 경쟁 우위만을 제공한다.
따라서 핵심 하위 도메인은 자연스럽게 복잡해진다.
회사의 핵심 비즈니스는 높은 진입장벽이 있어야 한다. 그래야 경쟁사가 모방하거나 복제하기 어려워진다.
경쟁 우위의 원천
핵심 하위 도메인이 반드시 기술이 들어가야 하는 것은 아니다.
회사의 경쟁 우위는 다양한 원천에서 나올 수 있다.
예를 들어 온라인으로 제품을 판매하는 보석 제조업체를 생각해보자.
온라인 쇼핑몰은 중요하지만 핵심 하위 도메인은 아니다.
보석 디자인이 이 회사의 핵심 하위 도메인이다.
좀 더 복잡한 예로, 수동 사기 탐지를 전문으로 하는 회사를 상상해보자.
이 회사는 분석가가 의심스러운 문서를 검토하고 잠재적인 사기 사례를 파악할 수 있도록 훈련시킨다.
가령 분석가가 이용하는 소프트웨어 시스템을 개발하고 있다고 하자. 이것은 핵심 하위 도메인일까?
아니다. 핵심 하위 도메인은 분석가가 수행하는 작업이다.
일반 하위 도메인
일반 하위 도메인(generic subdomain)은 모든 회사가 같은 방식으로 수행하는 비즈니스 활동을 말한다.
핵심 하위 도메인과 마찬가지로 일반 하위 도메인은 일반적으로 구현이 복잡하고 어렵다.
그러나 일반 하위 도메인은 회사에 경쟁력을 제공하지는 않는다.
예를 들어, 대부분의 시스템은 사용자를 인증하고 권한을 부여한다.
이때 전용 인증 메커니즘을 개발하는 대신 기존에 만들어진 솔루션을 사용하는 것이 더 합리적이다.
온라인에서 보석을 판매하는 업체로 돌아가보면, 보석 디자인은 핵심 하위 도메인이지만, 온라인 쇼핑몰은 일반 하위 도메인이다.
지원 하위 도메인
이름에서 알 수 있듯이 지원 하위 도메인(supporting subdomain)은 회사의 비즈니스를 지원하는 활동을 말한다.
그러나 핵심 하위 도메인과 달리 지원 하위 도메인은 어떠한 경쟁 우위도 제공하지 않는다.
지원 하위 도메인의 차별되는 특징은 솔루션의 비즈니스 로직의 복잡성이다. 지원 하위 도메인은 간단하다.
지원 하위 도메인의 비즈니스 로직은 대부분 데이터 입력 화면과 ETL(extract, transform, load) 작업과 유사하다. 이는 소위 말하는 CRUD(create, read, update, delete)와 유사하다.
하위 도메인 비교
이제 세 가지 유형의 하위 도메인의 차이점을 살펴보자.
경쟁 우위
핵심 하위 도메인만이 회사에 경쟁 우위를 제공한다.
핵심 하위 도메인은 경쟁사와 차별화를 가지기 위한 회사의 전략이다.
정의에 따르면 일반 하위 도메인은 경쟁 우위의 원천이 될 수 없다.
지원 하위 도메인은 진입장벽이 낮고, 경쟁 우위도 제공할 수 없다.
회사가 해결할 수 있는 문제가 더 복잡할수록 더 많은 비즈니스 가치를 제공할 수 있다.
이러한 복잡한 문제를 해결하면 비즈니스를 더욱 최적화하거나, 더 낮은 운영 비용으로 경쟁 우위를 얻을 수 있다.
복잡성
기술적인 관점에서 보면 하위 도메인의 유형에 따라 복잡성의 수준이 다르기 때문에 조직의 하위 도메인을 식별하는 것이 중요하다.
소프트웨어를 설계할 때 우리는 비즈니스 요구사항의 복잡성을 수용할 수 있는 도구를 선택해야 한다.
지원 하위 도메인의 비즈니스 로직은 간단하다.
이것은 기본적인 ETL 작업과 CRUD 인터페이스이며, 비즈니스 로직이 명확하다.
입력의 유효성을 검증하거나, 다른 구조의 데이터로 변환하는 것 이상의 로직을 벗어나지 않는다.
일반 하위 도메인은 훨씬 더 복잡하다.
다른 사람들이 이미 이러한 문제를 해결하는 데 시간과 노력을 투자한 데는 그럴 만한 이유가 있다.
예를 들어, 암호화 알고리즘이나 인증 메커니즘을 생각해보자.
지식 가용성 관점에서 일반 하위 도메인은 ‘알려진 미지’다. 이것은 여러분이 ‘모른다는 사실’을 알고 있는 것이다.
따라서 업계에서 인정하는 모범 사례를 사용하거나 전문 컨설턴트를 고용하여 맞춤형 솔루션을 설계할 수 있다.
핵심 하위 도메인은 복잡하다.
회사의 수익성이 좌우되게 때문에 경쟁업체가 최대한 모방하기 어려워야 한다.
그래서 회사는 전략적으로 핵심 하위 도메인으로 복잡한 문제를 해결하려고 한다.
때때로 핵심 하위 도메인과 지원 하위 도메인을 구별하는게 어려울 수 있다.
이때 복잡성은 도메인을 구별하는 유용한 지침이 된다.
하위 도메인을 부업으로 전환할 수 있는지 물어보자.
기꺼이 비용을 지불할 수 있는가? 그렇다면 이것은 핵심 하위 도메인이다.
지원 하위 도메인과 일반 하위 도메인을 구별하는 것도 비슷하다.
외부 솔루션을 연동하는 것보다 자체 솔루션을 구현하는 것이 더 간단하고 저렴한가? 그렇다면 지원 하위 도메인이다.
그림 1-1의 차트는 비즈니스 차별화와 비즈니스 로직 복잡성 측면에서 세 가지 유형의 하위 도메인 간의 상호작용을 나타낸다.
여기서 알 수 있는 것은
- 기능을 자체적으로 구현하는 것보다 일반적인 솔루션 연동이 더 간단하거나 저렴하다? → 일반 하위 도메인
- 자체 구현이 간단하고 저렴하다? → 지원 하위 도메인
변동성
앞서 언급했듯이 핵심 하위 도메인은 자주 변경될 수 있다.
한번의 시도로 문제가 해결될 수 있다면 경쟁자들도 빠르게 따라잡을 수 있기 때문에 아마도 경쟁 우위에서 좋은 위치는 아닐 것이다.
결과적으로 최적화된 솔루션을 찾아야 한다.
또한 핵심 하위 도메인에 대한 개선 작업은 지속적으로 혁신하고 발전해야 한다.
핵심 하위 도메인과 달리 지원 하위 도메인은 자주 변경되지 않는다.
기존 술루션이 있음에도 일반 하위 도메인은 시간이 지남에 따라 변경될 수 있다.
솔루션 전략
핵심 하위 도메인은 업계에서 기업이 다른 경쟁사와 경쟁할 수 있는 능력을 제공한다.
즉, 핵심 하위 도메인은 비즈니스가 중요하다.
또한 핵심 하위 도메인은 사내에서 구현되어야 한다.
핵심 하위 도메인의 요구사항은 자주, 지속적으로 변경될 것으로 예상되어 솔루션은 유지보수가 가능하고 쉽게 개선될 수 있어야 한다.
따라서 핵심 하위 도메인은 가장 진보된 엔지니어링 기술로 구현되어야 한다.
일반 하위 도메인은 어렵지만 이미 문제가 해결되었기에 이미 만들어진 제품을 구입하거나 오픈소스 솔루션을 채택하는 것이 비용 면에서 더 효율적이다.
지원 하위 도메인의 구현은 비즈니스 로직이 단순하고 변경의 빈도가 적기 때문에 적당히 진행하기 쉽다.
세 가지 유형의 하위 도메인의 차이점을 표 1-1에 정리했다.
하위 도메인 경계 식별
하위 도메인과 해당 유형을 식별하면 소프트웨어 솔루션을 구축할 때 설계와 관련된 의사결정에 상당한 도움이 된다.
그렇다면 실제로 해당 경계를 어떻게 식별할까?
하위 도메인과 그 유형은 기업의 비즈니스 전략에 따라 정의되며, 이는 동일한 분야에서 다른 회사와 경쟁하기 위해 자신을 차별화하는 방법이다.
대다수의 소프트웨어 프로젝트에서 하위 도메인은 어떤 식으로든 ‘이미 존재’한다.
하위 도메인 정제
크게 나눈 하위 도메인은 좋은 출발점이지만, 문제는 세부 사항에 있다.
비즈니스 기능의 복잡한 내용에 숨겨진 중요한 정보를 놓치지 않아야 한다.
고객 서비스 부서를 예로 들어보자.
내부적인 업무를 조사하면 전형적인 고객 서비스 부서가 헬프 데스크 시스템, 교대 근무 관리 및 일정, 전화 시스템 등과 같이 좀 더 세분화되어 있음을 알 수 있다.
- 핵심 하위 도메인 - 상담 사례 라우팅
- 일반 하위 도메인 - 헬프 데스크, 전화 시스템
- 지원 하위 도메인 - 교대 지원
특히 고객 상담을 라우팅 하는 경우, 과거에 비슷한 상담 사례를 성공적으로 처리한 상담원에게 상담을 전달할 수 있는 독창적인 알고리즘을 개발할 수 있다.
이 라우팅 알고리즘을 통해 경쟁업체보다 더 나은 고객 서비스를 제공할 수 있게 되므로 라우팅 알고리즘이 핵심 하위 도메인으로 볼 수 있다.
응집된 유스케이스를 하위 도메인으로
기술적인 관점에서 하위 도메인은 상호 연관되고 응집된 유스케이스의 집합과 유사하다.
이러한 유스케이스 집합에서는 보통 동일한 행위자(actor), 비즈니스 엔티티(business entity)를 포함하고 모두 밀접하게 관련된 데이터의 집합을 다룬다.
그림 1-3에 표시된 신용카드 결제 게이트웨이의 유스케이스 다이어그램을 보자.
이 유스케이스는 작업 중인 데이터 및 관련된 행위자와 밀접하게 연관되어 있다.
따라서 모든 유스케이스는 신용카드 결제 하위 도메인을 형성한다.
하위 도메인의 경계를 식별하기 위해 온 신경을 곤두세워 노력해야 할까?
핵심 하위 도메인에는 이러한 노력이 필요하다.
핵심 하위 도메인은 가장 중요하고, 변동성이 있고, 복잡하다.
따라서 가능한 한 많이 졍제하는 것이 중요하다.
핵심에 집중
하위 도메인은 소프트웨어 설계 의사결정을 내리는 프로세스의 어려움을 쉽게 해결하도록 돕는 도구다.
모든 조직에는 경쟁 우위를 제공하지만, 소프트웨어와는 아무 관련이 없는 비즈니스 기능이 꽤나 많다.
하위 도메인을 찾을 때 소프트웨어와 관련되지 않은 비즈니스 기능을 식별하고, 그 자체로 인정하며, 작업 중인 소프트웨어 시스템과 관련된 비지니스에 집중하는 것이 중요하다.
[도메인 분석 예제]
하위 도메인의 개념을 실제로 적용해서 여러 전략적 설계 의사결정을 하는데 활용하는 방법을 살펴보자.
Gigmaster와 BusVNext라는 가상의 두 회사가 있다.
Gigmaster
GigMaster는 티켓 판매 및 유통 회사다.
모바일 앱은 사용자의 음악 라이브러리, 스트리밍 서비스 계정, 소셜 미디어 프로필을 분석하여 사용자가 관심을 가질 만한 주변의 공연 정보를 찾아낸다.
GigMaster는 사용자의 개인 정보에 민감하여 모두 암호화 해서 저장한다.
그리고 회사의 추천 알고리즘은 익명 데이터만 사용한다.
앱의 추천 기능을 개선하기 위해 새로운 모듈이 구현되었다.
GigMaster를 통해 티켓을 구매하지 않더라도 사용자가 과거에 참석한 공연 정보를 기록할 수 있다.
비즈니스 도메인과 하위 도메인
Gigmaster의 비즈니스 도메인은 티켓 판매이며, 이것이 고객에게 제공하는 서비스다.
Gigmaster의 주요 경쟁 우위는 추천 엔진이다. 또한 회사는 사용자의 개인정보를 중요하게 생각하며 익명 데이터에 대해서만 처리한다.
명시적으로 언급하지 않았지만 모바일 앱의 사용자 경험도 중요하다.
따라서 핵심 도메인은
- 추천 엔진
- 데이터 익명화
- 모바일 앱
일반 하위 도메인은
- 암호화 - 모든 데이터 암호화
- 회계 - 회사가 영업을 하고 있기 때문에
- 정산 - 고객에게 청구
- 인증 및 권한 부여 - 사용자 식별
지원 하위 도메인은
- 음악 스트리밍 서비스와 연동
- 소셜 네트워크와 연동
- 참석 공연 모듈
로 볼 수 있겠다.
설계 의사결정
작동 중인 하위 도메인과 해당 유형 간의 차이점을 알면 이미 몇 가지 전략적인 설계 의사결정을 내릴 수 있다.
- 추천 엔진, 데이터 익명화, 모바일 앱은 가장 진보된 엔지니어링 도구와 기술을 사용하여 사내에서 구현돼야 한다. 이러한 모듈은 가장 자주 변경된다.
- 데이터 암호화, 회계, 정산, 인증에는 사용 또는 오픈소스 솔루션을 사용해야 한다.
- 스트리밍 서비스, 소셜 네트워크와의 연동과 참석한 공연을 위한 모듈 개발은 하청할 수 있다.
BusVNext
BusVNext는 대중교통 회사다.
고객에게 택시를 잡는 것처럼 쉽게 버스를 타는 경험을 제공하는 것이 목표다.
BusVNext의 고객은 모바일 앱을 통해 승차권을 예매할 수 있다.
예정된 출발 시간에 가까운 버스의 경로에 즉시 조정해서 지정된 출발 시간에 고객을 픽업한다.
회사의 주요 과제는 라우팅 알고리즘을 구현하는 것이다.
그 요구사항은 ‘외판원 문제(Traveling Salesman Problem)’의 변형이다.
라우팅 로직은 계속 조정되고 최적화된다.
예를 들어 통계에 따르면 탑승이 취소된 주된 이유는 버스가 도착하기까지 오랜 시간을 기다려야 하기 떄문이다.
그래서 하차가 지연되더라도 빠른 픽억을 우선시하는 라우팅 알고리즘을 만들었다.
비즈니스 도메인과 하위 도메인
BusVNext는 고객에게 최적화된 버스 승차 서비스를 제공한다.
비즈니스 도메인은 대중교통이다.
BusVNext의 주요 경쟁 우위는 다양한 비즈니스 목표를 우선시하면서, 동시에 복잡한 문제의 해결을 시도하는 라우팅 알고리즘이다.
또한 새로운 통찰력을 얻기 위해 지속적인 분석이 필요하다.
따라서 핵심 하위 도메인은
- 라우팅
- 분석
- 모바일 앱 사용자 경험
- 차량 관리
일반 하위 도메인은
- 교통 상황
- 회계
- 청구
- 권한 부여
지원 하위 도메인은
- 프로모션
- 할인 관리
등이 되겠다.
설계 의사결정
- 라우팅 알고리즘, 데이터 분석, 차량 관리, 앱 사용성은 가장 정교한 기술 도구와 패턴을 사용하여 사내에서 개발해야 한다.
- 판촉 관리 모듈의 구현은 외부에 위탁할 수 있다.
- 교통 상황 식별, 사용자 권한 관리, 재무 및 거래 기록 관리는 외부 서비스 제공 업체에 맡길 수 있다.
[도메인 전문가는 어떤 사람인가?]
이제 비즈니스 도메인과 하위 도메인에 대해 명확하게 이해했으니 다음 장에서 자주 사용할 또 다른 용어인 DDD 용어인 도메인 전문가(domain expoert)에 대해 살펴보겠다.
도메인 전문가란 우리가 모델링하고 코드로 구현할 비즈니스의 모든 복장성을 알고 있는 주제 전문가다.
도메인 전문가는 비즈니스를 대표한다. 또한 일반적으로 요구사항을 제시하는 사람 또는 소프트웨어 최종 사용자이다.
예를 들어 온라인 광고 대행사의 경우, 도메인 전문가는 캠페인 관리자, 미디어 구매자, 분석가, 그리고 기타 비즈니스 이해관계자가 될 것이다.
[결론]
핵심 하위 도메인
- 흥미로운 문제들, 기업이 경쟁자로부터 차별화하고 경쟁 우위를 얻는 활동이다.
일반 하위 도메인
- 해결된 문제들. 이것은 모든 회사가 같은 방식으로 하고 있는 일이다. 여기에는 혁신이 필요하지 않다.
- 사내 솔루션을 개발하는 것보다 기존 솔루션을 사용하는 것이 더 비용 효과적이다.
지원 하위 도메인
- 분명한 해결책이 있는 문제들. 사내에서 구현해야 할 활동이지만 경쟁 우위를 제공하지는 않는다.
Ch2. 도메인 지식 찾아내기
“운영환경에 배포되는 것은 도메인 전문가의 지식이 아니라 개발자의 이해 혹은 오해다.” - 알베르토 브랜돌리니(Alberto Brandolini)
1장에서는 비즈니스 도메인을 탐색하기 시작해서 기업의 비즈니스 도메인 또는 활동 영역을 식별하는 방법과 식별된 도메인에서 경쟁 전략을 분석하는 방법, 즉 비즈니스 하위 도메인의 경계와 유형을 식별하는 방법을 배웠다.
이번 장에서는 효과적인 커뮤니케이션과 지식 공유를 위한 도메인 주도 설계 도구인 유비쿼터스 언어를 배우고, 비즈니스 도메인의 복잡성을 이해하며, 비즈니스 로직을 소프트웨어 모델로 만들고 구현하는데 이를 활용해보자.
[비즈니스 문제]
우리가 개발하는 소프트웨어 시스템은 비즈니스 문제를 해결하는 솔루션이다.
여기서 언급한 문제는, 비즈니스 도메인의 컨텍스트에서 광범위하다.
비즈니스 문제는
- 워크플로우와 프로세스 최적화
- 수작업 최소화
- 자원 관리
- 의사결정 지원
- 데이터 관리
등과 관련한 과제일 수 있다.
하위 도메인은 세분화된 문제 도메인(problem domain)으로 특정 비즈니스 기능에 대한 솔루션을 제공하는 것이 목적이다.
[도메인 지식 찾아내기]
효과적인 소프트웨어 솔루션을 설계하려면 적어도 기본적인 비즈니스 도메인 지식이 있어야 한다.
이런 지식은 도메인 전문가의 몫이고, 우리는 될 필요도 없고, 될 수도 없다.
결국 중요한 것인 도메인 전문가를 이해하고 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이다.
효과적인 소프트웨어는 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야 한다.
비즈니스 문제와 요구사항 이면에 있는 이유에 대한 이해가 없다면, 솔루션은 비즈니스 요구사항을 소스코드로 ‘번역’한 것에 불과하다.
알베르토 브랜돌리니는 소프트웨어 개발은 배우는 과정이고, 작동하는 코드는 그 부산물이라고 했다.
소프트웨어 프로젝트의 성공은 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에 달렸다.
문제를 해결하려면, 문제를 이해해야 한다.
결국 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에는 효과적인 커뮤니케이션이 필요하다.
[커뮤니케이션]
거의 모든 소프트웨어 프로젝트에는 도메인 전문가, 프로젝트 소유자, 엔지니어, UI와 UX 디자이너, 프로젝트 매니저, 테스터, 분석가 등 다양한 역할의 이해관계자의 협업이 필요하다고 할 수 있다.
프로젝트와 연관된 모든 것에 대한 합의와 일치는 프로젝트의 성공에 필수다.
소프트웨어 프로젝트가 실패하는 이유에 대한 연구에서 효과적인 커뮤니케이션이 지식 공유와 프로젝트 성공에 필수라는 것을 밝혀냈다.
그림 2-1에서는 일반적인 커뮤니케이션의 모습을 보여준다.
전형적인 소프트웨어 개발 생애주기에서 도메인 지식은 분석 모델(analysis model)로 알려진 엔지니어 친화적인 형태로 ‘변환’된다.
분석 모델은 도메인 지식 이면에 존재하는 비즈니스 도메인에 기반하기보다는 시스템 요구사항을 설명한 것에 지나지 않는다.
의도는 좋을지 모르지만, 이런 식의 중재는 지식을 공유하는데 해를 끼친다.
결국에는 전달 과정에서 손실이 일어난다.
흔히 그렇듯이, 문서화된 커뮤니케이션은 최신 정보를 담아내지 못한다.
결국 소스코드가 프로젝트를 유지관리할 소프트웨어 엔지니어에게까지도 도메인 지식을 전달하는데 사용된다.
그림 2-2는 도메인 지식을 코드로 구현하는데 필요한 다양한 ‘변환’을 보여준다.
이런 소프트웨어 개발 과정은 우리나라로 치면 가족오락관에 ‘고요속의 외침’과 비슷한 면이 있다.
메시지를 전달하면서 종종 왜곡된 상태로 데이터가 전달된다는 의미다.
어떤 경우든 이런 경우 소프트웨어 프로젝트는 실패한다.
이 같은 문제를 해결하기 위해 더 나은 전달 방식이 있는데, 유비쿼터스 언어가 바로 그것이다.
[유비쿼터스 언어란 무엇인가?]
유비쿼터스 언어를 사용하는 것은 도메인 주도 설계의 초석이다.
아이디어는 간단하다. 참가자들이 효과적으로 소통하기 위해 같은 언어를 사용하는 것이다.
굉장히 상식적으로 들리지만, 볼테르(Voltaire)는 이렇게 말했다.
“우리가 말하는 상식은 실제로 일반적이지 않다(Common sense is not so common)”
전통적인 소프트웨어 개발 생애주기에서 변환이 어떻게 일어나는지 정리해보면 다음과 같다.
- 도메인 지식 → 분석 모델 → 요구사항 → 시스템 설계 → 소스코드
반면에 도메인 주도 설계에서는 이같이 도메인 지식을 계속해서 변환하는 대신, 단일화된 언어 체계를 세우고자 하는데, 그것이 유비쿼터스 언어다.
프로젝트와 관련된 모든 이해관계자는 비즈니스 도메인을 설명할 때 유비쿼터스 언어를 사용해야 한다.
가장 중요한 것은 도메인 전문가가 유비쿼터스 언어를 사용해 비즈니스 도메인을 추론하는데 편안해야 한다는 점이다.
[비즈니스 언어]
유비쿼터스 언어는 비즈니스 언어라는 점을 강조하고 싶다.
그렇기 때문에 기술 용어는 빼고 비즈니스 도메인에 관련된 용어로만 구성해야 한다.
유비쿼터스 언어는 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현하는 것을 목표로 한다.
시나리오
광고 캠페인 관리 시스템을 만들고 있다고 가정해보자.
- 광고 캠페인은 다양한 창의적인 자료를 전시할 수 있다.
- 캠페인은 최소한 하나의 광고 할당이 활성화되어야 게시된다.
- 판매 커미션은 거래가 승인된 후에 회계 처리된다.
모든 문장은 비즈니스 언어로 작성됐다.
반면 다음 문장은 철저히 기술적이어서 유비쿼터스 언어의 개념에 맞지 않는다.
- 광고의 아이프레임(iframe)은 HTML 파일을 표시한다.
- 캠페인은 ‘활성-할당(active-placement)’ 테이블에 하나의 연관 레코드가 있어야 한다.
- 판매 커미션은 거래(transaction) 테이블과 판매-승인(approved-sales) 테이블의 연관 레코드에 근거하여 처리된다.
후자의 문장은 순수하게 기술적이어서 도메인 전문가가 이해하기 쉽지 않다.
개발자가 이렇게 기술적인 관점으로 바라보는데만 익숙한 경우, 결국 비즈니스 로직을 완전히 이해하지 못해 효과적으로 솔루션을 구현하는 능력이 제한될 것이다.
일관성
유비쿼터스 언어는 반드시 정확하고 일관성이 있어야 한다.
가정할 필요가 없어야 하고, 비즈니스 도메인의 로직을 명료하게 표현해야 한다.
모호한 용어
어떤 비즈니스 도메인에서는 정책(policy) 이라는 용어가 규제 규칙 또는 보험 계약과 같은 여러 의미를 가진다.
정확한 의미는 맥락에 따라 사람 간의 상호작용을 통해서만 알 수 있다.
그러나 소프트웨어는 모호성에 잘 대처하지 못해, ‘정책’이라는 객체(entity)를 코드로 모델링하기가 어려울 수 있다.
유비쿼터스 언어는 용어마다 단일 의미를 갖게 하기 때문에 ‘정책’의 경우 ‘규제 규칙’과 ‘보험 계약’의 두 용어를 사용하여 명확한 모델을 만들어야 한다.
동의어
유비쿼터스 언어에서 두 용어는 서로 바꿔 사용할 수 없다.
예를 들어, ‘사용자’라는 용어는 수많은 시스템에서 사용한다.
그러나 도메인 전문가의 언어로 신중하게 설명하면 ‘사용자’, ‘방문자’, ‘관리자’, ‘계정’ 등의 다른 용어가 혼용된다는 것을 발견할 수 있다.
특정 컨텍스트 안에서 각각의 용어를 사용하는 것이 바람직하다.
[비즈니스 도메인 모델]
이번에는 모델링 관점에서 유비쿼터스 언어를 살펴보자.
모델이란 무엇인가?
모델이란 사물이나 현상에서 의도한 관점만 강조하고 다른 측면은 무시하며 간략히 표현한 것이다. 즉, 특정 용도를 마음에 둔 추상화된 결과다. - 레베카 워프스-브록(Rebeca Wirfs-Brock)
모델은 실세계의 복제가 아니라 우리가 실제 시스템을 이해하는데 도움을 주는 인간의 창조물이다.
모델을 잘 설명하는 예시 중 하나가 지도다.
그림 2-3의 예시와 같이 길 안내 지도, 지형도, 세계 지도, 지하철 노선도 등 모든 지도는 일종의 모델이다.
각 지도는 특정 목적을 지원하는데 충분한 자료만 담고 있다.
효과적인 모델링
모든 모델에는 목적이 있고, 효과적인 모델은 그 목적을 달성하는데 필요한 세부사항만 포함한다.
바로 이 점이 중요하다. 즉, 유용한 모델은 실세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 한다.
모델은 본질적으로 추상화의 결과다.
에츠허르 데이크스트라는 자신의 논문 “겸손한 프로그래머”에서 추상화의 목적은 모호함이 아니라 절대적으로정확할 수 있는 새로운 의미론적 수준(semantic level)을 만드는 것이라고 했다.
비즈니스 도메인 모델링
유비쿼터스 언어를 발전시키는 것은 사실상 비즈니스 도메인 모델을 구축하는 셈이다.
모델은 관련된 비즈니스 엔티티(business entity)와 그것의 행동, 인과 관계, 불변성 등을 반영해야 한다.
유비쿼터스 언어는 도메인의 모든 가능한 상세 정보를 포함하는 게 아니다.
대신, 모델은 필요한 시스템을 구현하는 데, 즉 소프트웨어가 해결하고자 하는 특정 문제를 해결하는데 필요한 만큼의 비즈니스 도메인 관점을 포함하면 된다.
이때, 엔지니어링 팀과 도메인 전문가의 효과적인 커뮤니케이션은 필수다.
비즈니스 도메인이 복잡할수록 커뮤니케이션의 중요성은 커진다.
비즈니스 도메인의 이해를 확인할 유일한 방법은 도메인 전문가가 이해할 수 있는 비즈니스 언어(유비쿼터스 언어)로 대화하는 것이다.
지속적인 노력
유비쿼터스 언어를 정형화(formulation)하라면 언어의 소유자인 도메인 전문가와의 상호작용이 중요하다.
모든 이해관계자는 모든 프로젝트와 관련된 커뮤니케이션에 유비쿼터스 언어를 지속적으로 사용해서 지식 공유를 확산하고 비즈니스 도메인에 대한 공유된 이해를 강화해야 한다.
가장 중요한 점은 유비쿼터스 언어르 발전시키는 것이 진행형이라는 것이다.
지속해서 검증하고 발전시켜야 한다.
모두가 이 언어를 일상적으로 사용하면 비즈니스 도메인에 대한 통찰을 얻을 것이다.
도구
유비쿼터스 언어를 수집하고 관리하는 과정을 돕는 도구와 기술이 있다.
예를 들어, 위키는 유비쿼터스 언어를 수집하고 관리하는 용어집(glossary)으로 사용될 수 있다.
이런 용어집은 비즈니스 도메인의 용어에 대한 정보를 얻을 수 있는 거점 역할을 한다.
또한 다 함께 용어집을 유지보수하는 것이 중요하다.
유비쿼터스 언어가 변경되면 모든 팀원이 수정할 수 있게 독려해야 한다.
프로젝트 용어집을 유지보수하는 것의 장점이 명백함에도 불구하고, 여기에는 본질적 한계가 있다.
용어집은 엔티티의 이름, 과정, 역할 등의 ‘명사(noun)’에만 효과적이다.
명사가 중요하긴 하지만, 행동(behavior)을 포착하는 것이 중요하다.
행동은 규칙, 가정, 그리고 불변성을 가진 실제 비즈니스 로직이다.
그러므로 용어집은 유스케이스 또는 거킨 테스트처럼 행동을 포착하는데 적합한 다른 도구와 함께 사용하는 것이 가장 중요하다.
거킨 테스트(Gherkin language)로 작성된 자동화 테스트는 유비쿼터스 언어를 포착하기에 좋은 언어일 뿐 아니라 도메인 전문가와 소프트웨어 엔지니어의 간극을 메우는 보조 도구로서의 역할을 할 수 있다.
거킨 언어로 작성된 다음 예제 테스트를 살펴보자.
- Scenario: 에이전트에게 새로운 지원 케이스에 대해 알린다.
- Given: 빈센트 줄스는 다음 내용을 담은 새로운 지원 케이스를 제출한다:
- “나는 AWS Infinidash를 설정하는데 도움이 필요하다.”
- When: 티켓이 울프 씨에게 할당된다.
- Then: 에이전트는 새로운 티켓에 대해 알림을 받는다.
거킨 기반의 테스트 스위트를 관리하는 것은 때때로 어려운 일이다.
그러나 복잡한 비즈니스 도메인인 경우 확실히 가치가 있다.
마지막으로 유비쿼터스 언어의 용어의 사용을 검증할 수 있는 정적 코드 분석 도구도 있다.
이런 도구 중 주목할만한 예는 NDepend다.
이런 도구가 유용하긴 하지만, 일상적인 상호작용에서 사용하는 것보다는 못하다.
도전과제
이론상으로 유비쿼터스 언어를 발전시키는 것이 간단한 과정 같지만 실제로는 그렇지 않다.
도메인 지식을 수집하는 신뢰할만한 유일한 방법은 도메인 전문가와 대화를 해보는 것이다.
이 기법에 경험이 쌓이면 단순히 존재하는 지식을 발견하는 것뿐만 아니라 도메인 전문가와 협럭해서 모델을 함께 만들어가는 것이 자주 포함되는 사실을 알게 된다.
또한 비즈니스 도메인의 특성에 대해 질문하면 종종 숨어있던 충돌과 공백을 찾아내 명확하게 할 수도 있다.
이는 특히 핵심 하위 도메인의 경우에 일반적이다.
이런 과정은 도메인 전문가가 자신의 영역을 더 잘 이해하도록 돕는 상호보완적인 배움의 과정이기도 하다.
[결론]
효과적인 커뮤니케이션과 지식 공유는 성공적인 소프트웨어 프로젝트에 필수다.
소프트웨어 엔지니어가 소프트웨어 솔루션을 설계하고 개발하기 위해서는 반드시 비즈니스 도메인을 이해해야 한다.
'Book Notes' 카테고리의 다른 글
| [개발서적] 도메인 주도 설계 첫걸음 2부(ch5~6) 요약 (1) (0) | 2026.01.11 |
|---|---|
| [개발서적] 도메인 주도 설계 첫걸음 1부(ch3~4) 요약 (2) (0) | 2026.01.10 |
| [개발서적] Clean Architecture 6부(ch30~34) 요약 (4) (0) | 2025.12.15 |
| [개발서적] Clean Architecture 5부(ch25~28) 요약 (3) (0) | 2025.12.10 |
| [개발서적] Clean Architecture 5부(ch20~24) 요약 (2) (1) | 2025.12.10 |