DDD. That's not how you do it

https://www.youtube.com/watch?v=sLG5n_pXWK0&ab_channel=우아한테크

📌 DDD, 그거 그렇게 하는 거 아닌데 – 발표 정리

발표자: 박재성 (우아한형제들, 서버 개발자 / 우아한테크코스 모바일 캡틴)

🧭 발표 목적

  • 도메인 주도 설계(DDD)를 잘못 이해하고 도입하려는 시도를 되짚어봄

  • 그린필드/브라운필드 상황별 DDD 도입 실천 방안 제시

  • 실제 팀 내 설계·협업 과정에서의 인사이트 공유

1️⃣ 도메인 주도 설계(DDD)란?

  • 정의: 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 원칙과 패턴의 모음.

  • 출처: 에릭 에반스의 『Domain-Driven Design』 (2003)

  • 중요 포인트: 복잡성을 다루는 철학적 접근이 핵심이지, 특정 디자인 패턴만을 의미하지 않음.

  • 기반 철학: 객체지향(OOP), 애자일

2️⃣ 잘못된 DDD 도입 사례 (그린필드 기준)

💥 문제적 문장 3가지

  1. “DDD 하려면 클린 아키텍처 or 헥사고날 아키텍처를 써야 해요”

  2. “서비스를 먼저 나눠서 마이크로서비스 아키텍처(MSA)를 시작할게요”

  3. “애그리거트, 도메인 이벤트를 도입하려면 완벽한 설계가 필요해요”

👉 공통된 문제:

  • 구현부터 접근

  • 용어만 강조하며 맥락이나 목적 없는 도입

  • 팀 내 합의와 컨텍스트 없이 구조만 흉내냄

3️⃣ 그린필드에서의 DDD

🧠 오스트랄로피테쿠스 패턴

"들으면 어려워 보이는 생소한 용어만 먼저 도입하는 행태"

  • 예: TDD, BDD, 자일 등 무작정 도입

  • 해결: “문제가 뭔지 → 왜 이 방법이 유효한지” 먼저 대화하고, 기술은 도구로만 활용

🔍 마이크로서비스 프리미엄

“서비스 먼저 나누고 보자” → 오히려 복잡성만 증가

  • 해결:

    • 초기에는 모놀리식으로 시작

    • 단일 패키지 → 점진적 리팩토링 → 모듈 분리 → 필요 시 MSA

    • 핵심은 아키텍처보다 올바른 **경계(바운디드 컨텍스트)** 도출

      • 즉, 도메인 분석에 대한 시간을 가져야 함

🧱 완벽한 설계는 없다

변화는 필연. 완벽한 설계를 고집하면 실행 불능

  • 요구사항은 항상 변한다.

  • 설계는 유연하고 자율성을 내포해야 함 → 변화 자체를 내재화하는 프로세스를 만든다. (애자일)

  • ‘완벽’보다는 '점진적 개선' + '자기 설명 가능한 코드' 지향

4️⃣ 코드에서 시작하는 DDD

⚙️ 게터/세터는 나쁘지 않다

  • 초기에는 getter/setter도 괜찮음

  • 점차적으로 의미 있는 메서드로 리팩토링 → 풍부한 도메인 모델

// Before
car.setPosition(car.getPosition() + 1);
// After
car.move();

  • OOP는 분명 DDD의 기반이지만, OOP는 DDD와 동일하지 않다.

💬 유비쿼터스 언어

  • 클래스나 함수의 이름을 짓기가 너무 어렵기에 도입

  • 모든 팀원이 같은 용어를 공유해야 함 (디자이너/기획자 포함 프로젝트의 모든 곳에서 사용)

  • 용어 사전은 명사뿐 아니라 동사도 포함

  • README와 함께 리비전 관리하여 살아있는 문서로 유지(형상관리)

    • 용어사전

      Image

    • 인수 테스트

      Image

      고객의 관점에서 소프트웨어가 어떻게 작동하는지를 고려한다.

5️⃣ 브라운필드에서의 DDD

  • 브라운필드? → 출시 후 어제까지 작성한 코드가 있는 프로젝트

🎯 비즈니스 도메인을 이해해야 하는 이유

  • 개발자의 월급은 비즈니스의 성공에서 나온다

  • 비즈니스 도메인 = 소프트웨어로 해결하고자 하는 문제 영역

  • 비즈니스 = 사용자의 활동과 관심사

  • 하위 도메인으로 분해: 상품, 전시, 결제, 정산 등

🔍 도메인 분류 기준

  • 어디서, 어떻게 돈을 벌 것인가? 우리의 비전은 무엇인가?

  • 코어 / 서포팅 / 제너릭 (ex. 코어 = 주문, 제너릭 = 이메일 전송)

  • 아래는 core domain chart

    Image

  • 팀 역량/자원 배분도 이에 따라 조정

📊 활용 도구

  • 이벤트 스토밍, 도메인 스토리텔링, 컨텍스트 매핑 등 시각화 도구 활용

이제 비즈니스 문제를 어떻게 해결해야할 지 고민

6️⃣ 경계를 나누는 기준

✂️ 바운디드 컨텍스트 나누기(문제를 해결하기 위해 범위를 좁혀야 함)

  • 바운디드 컨텍스트 = 복잡한 도메인을 명확하게 분리된 영역으로 나누는 단위

  • 같은 용어라도 다른 의미로 쓰일 때 (ex. ‘과제’ vs ‘과제 제출물’)

  • 외부 시스템 격리 등 개발자 의견

  • 모두가 다르게 생각할 수 있음을 인정하고, 함께 그림 그려보기

시작은 단순하게, 점진적 분리 → “작고 중요한 것부터” (작은 문제를 하나씩 해결)

7️⃣ 외부와 단절하는 3가지 패턴

  • 외부 시스템과 통합하다보면 용어나 로직이 오염됨. (예: userId ↔ memberId)

  1. DTO: 외부 데이터 수용을 위한 구조체

  2. DIP: 의존성 역전

  3. ACL (Anti-Corruption Layer):

    • 외부 시스템의 모델/용어가 내부로 침범하지 않도록 차단

    • 번역 계층, Adapter 계층 등으로 구현

    • 외부 시스템을 쉽게 교체하는 장점을 얻을 수 있음

8️⃣ 자연스러운 아키텍처 형성

  • DTO, DIP, ACL을 적용하다보면 자연스럽게 아키텍처가 그려짐

  • 핵사고날/클린 아키텍처는 결과물이지 목표가 아님

    • 핵사고날: 시스템을 중심에 두고, 포트와 어댑터를 통해 외부와 소통한다. (호환성 높임)

    • 클린: 외부 기술은 언제든 교체될 수 있어야 한다. (구현체만 갈아끼움)

  • 처음부터 도입하지 말고, 필요에 따라 진화시켜 나가기

  • 구현 → 점진적 리팩토링 → 아키텍처 도출

9️⃣ 조직 내 확산 전략

  • 변화를 유도할 사람이 필요(동맹)

  • 호기심 유발 (ex. 화이트보드 낙서)

    • 실제 발표자의 화이트보드

      Image

  • Issue 발급 → 자연스러운 논의 유도 → 동료 설득

1️⃣0️⃣ 마무리 메시지

  • DDD는 도구가 아니라 철학

  • "우리에게 왜 필요한가?"라는 질문부터 시작하라

  • 개발을 잘하는 것이 아니라, 프로젝트를 잘하는 방법이다

  • 프로젝트에 도움이 되는 DDD 아이디어를 필터링 하여 적용

📚 추천 도서

  • 『소프트웨어 장인』

  • 『팀 토폴로지』

  • 『소프트웨어 아키텍처 101』

🎯 발표에서 주목해야 할 핵심 포인트 (What to Focus On)

핵심 메시지
설명
왜 중요한가

기술보다 문제 정의가 먼저다

“DDD 하자”는 말보다, **왜 필요한가?**를 먼저 설명해야 한다

기술 도입의 본질은 문제 해결이다

아키텍처는 진화시켜야 한다

처음부터 클린/헥사고날 아키텍처를 적용하지 말고, 구현하며 점진적으로 리팩토링하라

실무에서 처음부터 완벽한 구조를 잡는 건 환상이다

완벽한 설계는 없다

요구사항은 계속 바뀌므로 “완벽한 설계”를 추구하면 실행 자체가 안 됨

설계보다 변화 대응 능력이 중요

용어 정리는 진짜 중요하다

유비쿼터스 언어와 용어 사전은 협업 효율과 도메인 이해에 필수

코드를 명확하게 설명할 수 있어야 유지보수가 쉬워진다

바운디드 컨텍스트는 구체적 경계다

같은 단어라도 문맥이 다르면 컨텍스트를 나눠야 한다

설계 충돌을 방지하고 팀 간 협업을 원활히 만든다

느낀점

DDD에 대해 막연하게만 알고 있었는데, 이번 발표를 통해 도메인 중심의 사고방식이 왜 중요한지를 알게 되었습니다.

  • ‘완벽한 설계는 존재하지 않는다’는 메시지와, 바운디드 컨텍스트를 함께 그려보자는 제안이 인상 깊었습니다.

  • ‘외부와 단절하기 위한 3가지 패턴’, ‘어떻게 용어를 정리하고 점진적으로 나누는지’ 등의 구체적인 방법들이 큰 도움이 되었습니다.

PreviousAPI Gateway PatternNextCS Note for Interview

Last updated