Skip to content

Ubiquitous Language (UL)

도메인 주도 설계(Domain-Driven Design, DDD)의 가장 강력하고 핵심적인 도구는 보편적 언어(Ubiquitous Language)다.

  • 팀의 공통 언어: 도메인 전문가, 설계자, 개발자가 소통을 위해 사용하는 공유된 언어 체계
  • 모호함의 제거: 동일한 개념에 대해 서로 다른 용어를 사용하여 발생하는 오해 방지
  • 지식의 축적: 프로젝트 구성원 모두 도메인 모델을 이해하고 발전시키는 기반

소프트웨어 개발 과정에서 개발자와 비즈니스 전문가 사이에는 언어적 장벽이 존재한다.

graph TD
subgraph "기존의 방식 (통역 필요)"
A[도메인 전문가] -- " 비즈니스 언어 " --> B(기획자/분석가)
B -- " 요구사항 정의서 " --> C[개발자]
C -- " 기술적 구현 " --> D{소프트웨어}
D -. " 오해와 왜곡 발생 " .-> A
end
  • 소통의 단절: 전문가는 비즈니스 용어를 사용하고 개발자는 기술적 용어를 사용
  • 번역 비용의 발생: 회의 내용을 코드로 옮기거나 코드를 설명할 때 끊임없는 통역 필요
  • 설계의 왜곡: 번역 과정에서 비즈니스의 핵심 의도가 누락되거나 잘못 반영

이러한 문제를 해결하기 위해 문서, 대화, 코드에 모두 동일하게 적용되는 단일한 언어를 구축해야 한다.

보편적 언어는 단순히 용어집을 만드는 것 이상의 의미를 가지며 살아있는 모델과 연결되어야 한다.

기술 중심 용어보편적 언어 (도메인 중심)이유
saveUserDataregisterMember비즈니스 행위를 명확히 표현
order_status = 1OrderState.PLACED상태의 의미를 코드로 전달
updateBalancewithdrawMoney구체적인 비즈니스 맥락 반영
  • 전방위적 사용: 구두 대화, 화이트보드 그림, 이메일, 문서, 코드, 테스트 케이스에 모두 사용
  • 엄격한 일관성: 특정 컨텍스트 내에서 하나의 용어는 반드시 하나의 명확한 의미만 가짐
  • 지속적인 진화: 도메인에 대한 이해가 깊어짐에 따라 언어도 함께 정제되고 수정됨

보편적 언어의 진정한 가치는 코드가 도메인을 그대로 설명할 때 발현된다.

// 잘못된 예: 기술적 용어나 모호한 표현 사용
public void process(Order order) {
if (order.getStatus() == 1) {
order.updateStatus(2);
}
}
// 올바른 예: 보편적 언어를 메서드와 상태명에 반영
public void ship(Order order) {
if (order.canBeShipped()) {
order.markAsShipped();
}
}
  • 도메인 주도 로직: process 같은 추상적인 단어 대신 ship, cancel, refund 등 도메인 용어 사용
  • 자기 설명적 코드: 코드를 읽는 것만으로도 비즈니스 전문가와 논의한 규칙을 확인 가능
  • 테스트의 문서화: 테스트 코드의 시나리오가 비즈니스 요구사항과 동일한 언어로 작성됨

보편적 언어 구축을 위한 실천 전략

Section titled “보편적 언어 구축을 위한 실천 전략”

성공적인 보편적 언어 구축을 위해서는 팀 전체의 의도적인 노력이 필요하다.

  • 용어 사전 관리: 팀 내에서 합의된 용어와 정의를 기록하고 수시로 공유
  • 전문가와의 직접 소통: 중간 매개체 없이 개발자가 직접 도메인 전문가의 언어를 듣고 질문
  • 언어의 강제성: 코드나 문서에서 합의되지 않은 용어가 발견되면 즉시 보편적 언어로 교체
  • 시각적 도구 활용: 다이어그램이나 프로토타입을 통해 언어의 연결 관계를 시각화

보편적 언어가 ‘보편적’이라는 의미는 전사적인 공용 언어를 뜻하는 것이 아니라 특정 경계 안에서 유효함을 의미한다.

  • 컨텍스트별 경계: Account라는 단어가 은행 컨텍스트에서는 ‘계좌’이지만 결제 컨텍스트에서는 ‘계정’일 수 있음
  • 모델의 파편화 방지: 경계를 명확히 설정함으로써 용어 충돌을 피하고 각 컨텍스트에 최적화된 언어 유지

보편적 언어는 개발자와 전문가가 함께 도메인 모델을 탐구하는 과정이며, 이를 통해 소프트웨어는 비즈니스 가치를 정확히 담아낼 수 있다.

Last updated:

DDD