도메인 주도 설계 첫걸음 - 유비쿼터스 언어

Introduction

• 개요
• 유비쿼터스 언어
  • 비즈니스 도메인의 언어는 항상 명확하지 않다.
  • 예시 설명.
  • 유비쿼터스 언어의 필요성.
• 도메인 커뮤니케이션이란?
  • 도메인 커뮤니케이션의 핵심 개념
• 예시 설명 1) 온라인 쇼핑몰의 ‘반품’ 개념
  • 부서별로 다른 ‘반품’의 정의.
  • 유비쿼터스 언어 도입.
• 예시 설명 2) 병원 예약 시스템의 ‘진료 완료’ 개념
  • 부서별로 다른 ‘진료 완료’의 의미
  • 유비쿼터스 언어 도입.
• 결론
  • 커뮤니케이션은 일방적인 지식 전달이 아니라, 피드백을 반영하는 과정이 되어야 한다.
  • 도메인 커뮤니케이션이 잘 이루어진다면?

개요

프로젝트 개발 과정에서 유사한 개념이 혼재되어 팀 간 커뮤니케이션에 어려움이 발생했습니다.

• 같은 용어가 서로 다른 의미로 해석되거나, 기대했던 기능과 실제 구현이 엇갈리는 상황이 반복되면서, 명확한 개념 정의와 의사소통의 중요성을 깨닫게 되었습니다.

이를 해결하기 위해 '도메인 주도 설계 첫걸음'을 읽으며, 도메인 모델과 유비쿼터스 언어가 어떻게 적용될 수 있는지 탐구하고 정리하게 되었습니다.

실제 프로젝트에서 발생하는 커뮤니케이션 문제를 어떻게 개선할 수 있을지 고민하며 정리해 보고자 글을 작성하게 되었습니다.

유비쿼터스 언어

비즈니스 도메인의 언어는 항상 명확하지 않다.

• 도메인에서 사용되는 용어는 일관되지 않거나 불명확할 수 있다.
• 사전적인 정의가 아니라, 특정 조직이나 팀에서만 통용되는 용어가 많다.
• 같은 개념을 두고도 다른 부서, 다른 사람마다 다른 표현을 사용할 수 있다.

예시 설명.

전자상거래 도메인에서 고객이라는 용어가 있다고 생각해보자.

• 마케팅 팀: "고객"은 이메일을 수신하는 사람을 의미한다.
• 영업 팀: "고객"은 실제로 상품을 구매한 사람을 의미한다.
• 개발 팀: "고객"은 회원가입을 한 사용자를 의미한다.

이렇게 같은 고객이라는 단어가 부서별로 다르게 사용되면, 혼란이 발생하고 커뮤니케이션 오류가 생길 가능성이 높아진다.

유비쿼터스 언어의 필요성.

"저 사람의 말을 믿고 우리 서비스에 도입해도 되는 거야? 안 되는 거야?"

• 도메인 언어가 명확하지 않으면, 의사결정이 어려워진다.
• 팀 전체가 공유할 수 있는 "하나의 명확한 언어"가 필요하다.
• 유비쿼터스 언어는 도메인 지식을 코드에 직접 반영할 수 있도록 한다.

도메인 커뮤니케이션이란?

도메인 전문가와 개발팀 간의 의사소통 과정을 의미한다.

소프트웨어 개발에서 중요한 것은 도메인 지식을 시스템에 반영하는 것이며, 원활한 커뮤니케이션이 필수적이다.

도메인 커뮤니케이션의 핵심 개념

• 단방향이 아닌 양방향 흐름
  • 도메인 전문가가 지식을 전달하면 개발팀이 코드로 변환한다고 생각하지만, 실제로는 개발팀이 구현한 시스템을 도메인 전문가가 사용하면서 새로운 요구사항이 추가되거나 기존 개념이 변화하는 과정이 포함된다.
• 커뮤니케이션 단절이 발생하면 문제 발생
  • 도메인 전문가와 개발팀 간의 커뮤니케이션이 원활하지 않으면, 개발팀이 잘못된 요구사항을 구현하거나 도메인의 핵심 로직을 빠뜨릴 가능성이 있다.
• 유비쿼터스 언어의 필요성
  • 서로 다른 직군에서 동일한 개념을 다르게 표현하는 경우가 많기 때문에, 모든 팀이 공유할 수 있는 명확한 용어(유비쿼터스 언어)를 정리하는 것이 중요하다.

예시 설명 1) 온라인 쇼핑몰의 ‘반품’ 개념

부서별로 다른 ‘반품’의 정의.

전자상거래 서비스에서 ‘반품’이라는 용어를 생각해보자.

• 고객 지원팀: 반품 요청이 접수되면 반품이 완료된 것으로 간주
• 물류팀: 실제로 상품이 창고로 도착해야 반품 완료
• 회계팀: 환불이 완료되어야 반품이 끝남
• 개발팀: 반품 상태가 데이터베이스에서 ‘완료’로 변경되어야 반품이 끝남

이처럼 같은 ‘반품’이라는 개념이 부서별로 다르게 정의되면, 각 팀이 의사결정을 내릴 때 혼란이 발생할 수 있다.

유비쿼터스 언어 도입.

• 모든 팀이 동일한 개념을 이해할 수 있도록 ‘반품 프로세스’를 명확하게 정의 한다.
  • ex) 반품 단계를 ‘반품 요청 → 반품 승인 → 물류 반품 완료 → 환불 완료’로 나누고, 각 단계에서 담당하는 팀을 지정하여 모든 부서가 공통된 이해를 가질 수 있도록 한다.

이렇게 하면 개발팀도 정확한 상태값을 정의할 수 있고, 각 팀이 반품 프로세스를 명확하게 이해하면서 커뮤니케이션 오류를 줄일 수 있다.

예시 설명 2) 병원 예약 시스템의 ‘진료 완료’ 개념

부서별로 다른 ‘진료 완료’의 의미

병원 예약 시스템에서 ‘진료 완료’ 상태는 부서마다 다르게 해석될 수 있다.

• 접수팀: 환자가 병원에 도착하고 접수하면 ‘진료 완료’
• 의료진: 실제로 진료가 끝나야 ‘진료 완료’
• 보험 청구팀: 진료비가 결제되고 보험 청구가 가능해야 ‘진료 완료’
• IT 개발팀: 시스템에서 ‘완료’ 상태로 업데이트되어야 ‘진료 완료’

유비쿼터스 언어 도입.

• ‘진료 완료’ 단계를 명확하게 정의하여 모든 부서가 동일한 개념을 공유
  • ex) ‘접수 완료 → 진료 진행 중 → 진료 완료 → 결제 완료’ 등의 상태를 정의 한다.
• 이렇게 하면 개발팀도 정확한 상태값을 코드에 반영할 수 있고, 각 팀이 같은 기준을 바탕으로 업무를 수행할 수 있다.

결론

• 도메인 전문가와 개발팀이 같은 개념을 다르게 해석하면, 잘못된 시스템이 만들어질 가능성이 높아진다.
  • 곧 서비스의 오류, 사용자의 혼란, 비즈니스 손실로 이어질 수 있다.
• 예를 들어
  • 주문 상태를 "배송 완료"라고 했을 때, 개발팀은 상품이 물류창고에서 출발한 상태로 해석할 수 있지만, 고객 서비스팀은 상품이 고객의 손에 도착한 상태라고 이해할 수도 있다.

따라서 모든 팀이 공통된 개념을 공유할 수 있도록, 유비쿼터스 언어를 정립하고 이를 기반으로 커뮤니케이션하는 것이 필수적이다.

프로젝트 초기에 반드시 도메인 용어 정의 과정을 포함해야 한다.

• 반품 프로세스, 진료 완료, 주문 확정과 같은 핵심 용어를 명확하게 정의한 문서를 작성하고, 이를 코드, 데이터 모델, API 명세서 등에 일관되게 반영하는 것이 중요하다.

커뮤니케이션은 일방적인 지식 전달이 아니라, 피드백을 반영하는 과정이 되어야 한다.

• 도메인 전문가가 설명하는 개념이 완벽할 것이라는 가정은 위험하다. 개발팀이 시스템을 구축하면서 기존 개념의 문제점이 드러나거나, 더 나은 방식이 발견될 가능성이 높다.

따라서, 개발팀은 도메인 전문가의 설명을 그대로 구현하는 것이 아니라, "이 방식이 정말 비즈니스 요구사항을 충족하는가?"를 지속적으로 검토해야 한다.

도메인 커뮤니케이션이 잘 이루어진다면?

• 시스템이 비즈니스 요구사항을 정확히 반영할 수 있다.
• 개발 속도가 빨라지고, 재작업 비용이 줄어든다.
• 부서 간 커뮤니케이션 오류가 줄어든다.
• 유비쿼터스 언어를 통해 모든 팀이 같은 개념을 공유할 수 있다.

결국, 비즈니스와 기술이 함께 성장하는 선순환 구조를 만들 수 있다.