[DDD-Quickly] 1,2장 요약 정리 - DDD와 유비쿼터스 언어

이번 포스팅에서는 “도메인 주도 설계(Domain-Driven Design, DDD)”가 무엇인지 개념을 정리해보려고 합니다. 최근 업무를 하면서 가장 큰 고민이 좋은 설계는 어떻게 해야하는건지를 많이 생각했습니다. 사이드 프로젝트를 진행하기 전 DDD에 대해 학습하고, 이를 프로젝트에 적용하면서 실무에 도움이 될 수 있도록 하는게 이번 책을 학습하는 목표입니다.

---

1. 도메인 주도 설계(DDD)란 무엇인가?

소프트웨어는 현실 세계의 문제를 효율적으로 해결하거나, 복잡한 비즈니스 로직을 자동화하기 위해 만들어집니다. 이때 우리가 다루는 현실 세계(또는 비즈니스 문제) 자체를 “도메인(Domain)”이라고 부릅니다. 도메인 주도 설계는 다음과 같은 특징을 갖습니다:

• 현실 세계의 프로세스나 비즈니스 로직을 소프트웨어로 옮기려면, 도메인에 대한 깊은 이해가 필요하다.
• 소프트웨어 각 구성 요소(Class, Interface 등)는 도메인의 핵심 개념을 “정확하게” 표현해야 한다.
• 이를 위해서는 도메인 지식을 기반으로 한 “도메인 모델”이 설계의 중심에 있어야 한다.

1) 폭포수 설계 vs 애자일, 그리고 DDD

소프트웨어 설계를 하는 대표적인 방식으로 많이 알려진 ‘폭포수 모델(Waterfall)’과 ‘애자일(Agile)’ 방법론이 있습니다.

• 폭포수 모델은 요구사항 → 분석 → 설계 → 개발 단계가 선형적으로 진행되어서, 지식이 일방통행식으로 전달되는 문제가 있습니다.
• 애자일 방법론은 지속적인 개선과 피드백을 받아볼 수는 있지만, 견고한 설계 근거가 없이 리팩터링만 반복할 경우 오히려 복잡도가 증가할 수 있습니다.
• 도메인 주도 설계는 “설계”와 “개발”을 긴밀히 연결해, 실제 개발 과정에서 나타나는 피드백을 설계에 반영하고, 설계가 업데이트되면 개발이 더 빨라지는 선순환을 추구합니다.

2) 도메인 모델(Domain Model)

도메인 모델이란, 현실 도메인을 추상화하여 논리적으로 구성한 “설계의 근간”입니다. DDD에서는 이 모델이 다음과 같은 역할을 강조합니다.

• 모든 팀원(개발자, 아키텍트, 도메인 전문가 등)이 모델을 통해 의사소통한다.
• 도메인 모델을 기준으로 코드를 작성하므로, 모델과 코드가 서로 밀접하게 맞물려 있어야 한다.
• 특정 UML 다이어그램만을 모델이라 부르지 않는다. 모델은 도메인을 표현하는 모든 설계 아이디어와 개념의 뼈대이자 지향점이 된다.

아래는 DDD의 예시로, 항공 교통 감시 시스템을 설계할 때의 간단한 모델 스케치 예시입니다:

data class Airplane(
    val flightNumber: String,
    val position: Coordinates,
    val scheduledRoute: List<Coordinates>
)

data class Coordinates(
    val latitude: Double,
    val longitude: Double
)

// 예: 특정 항공기가 예정된 경로를 제대로 따르는지, 충돌 위험이 없는지 등을 체크하는 기능들

• “항공 교통 관제”라는 도메인의 필수 개념(항공기, 좌표, 경로 등)을 코드 클래스에 담아내는 방식

---

2. 유비쿼터스 언어 (Ubiquitous Language)

도메인 주도 설계를 성공으로 이끄는 또 다른 핵심 개념은 “유비쿼터스 언어”입니다.

1) 모두가 통일된 언어를 사용하자

• 현실 세계의 전문가(도메인 전문가)는 도메인 용어(전문용어)를 사용한다.
• 개발자들은 설계나 기술적인 표현을 쓰기 마련이다.
• 이 둘이 제대로 소통하지 못하면, 결국 도메인 지식이 왜곡되어 코드에 반영될 수밖에 없다.

따라서 DDD에서는 “프로젝트 구성원 모두가 공통으로 사용하는 언어(모델 기반의 언어)”를 명시적으로 정의하라고 제안합니다. 이를 가리켜 “유비쿼터스 언어(Ubiquitous Language)”라고 합니다.

2) 코드와 문서를 일치시키기

DDD에서는 모델에 해당하는 용어와 개념을 코드 레벨에서도 최대한 동일하게 유지하라고 강조합니다. 예를 들어, 항공 도메인에서 “항공기의 경로”가 “Route”라는 개념으로 정의되었다면, 코드에서도 “Route”라는 클래스로 표현하는 식입니다.

data class Route(
    val checkpoints: List<Coordinates>
)

fun Airplane.isFollowingRoute(currentPosition: Coordinates): Boolean {
    // 도메인에서 정의된 '경로(Route)'와 항공기의 현재 위치를 비교하는 로직
    return ...
}

• 자바 독(주석), 스펙 문서, 기획서, 디자인 다이어그램까지 모두 같은 용어(“Route”, “Checkpoints” 등)를 사용하도록 맞춰주어야, 커뮤니케이션 오류가 줄어듭니다.

---

✏️ 마무리 정리

1. 도메인 주도 설계(DDD)는 소프트웨어가 해결해야 할 현실 세계의 문제(도메인)에 대한 깊은 이해를 바탕으로, “모델”을 중심에 두고 개발과 설계를 함께 이끌어가는 방법론입니다.
2. 폭포수 모델, 애자일의 장·단점을 보완해, 설계와 개발이 동시에 발전하는 선순환 구조를 지향합니다.
3. 도메인 모델을 명확히 정의하고, 팀원 모두가 이를 기반으로 소통하기 위해 “유비쿼터스 언어”를 사용합니다.
4. 모델의 주요 개념과 용어를 코드에 그대로 반영해, 도메인 전문가와 개발자가 같은 언어로 소통하게 하는 것이 가장 중요합니다.

특히 마지막에 있는 도메인 전문가와 개발자가 같은 언어로 소통하는게 아주아주 인상 깊었고, 와닿았습니다. 최근 개발을 진행하면서 결제 관련 로직을 수정하는데 purchase라는 구매하기 메소드를 "구매" 라는 용어로 내부 개발자들이 부르고 있어서 회의 중 혼란을 겪은 일이 있었습니다.

개발자들간에 혼동이 생기기도 하는데 이런 부분에서 도메인 전문가(비개발자)와는 더욱 같은 언어로 소통하는게 중요한 것임을 깨달았던 것 같습니다.