마이크로서비스 설계의 핵심, DDD 5분 완벽 정리

📚 같이 보면 좋은 글

• • 계획 짜느라 시간 낭비, 이젠 여행만 즐기는 법 Planit
• • 벼락치기 대신 똑똑하게 공부하는 단 하나의 방법, Quizlet
• • 오늘 저녁 뭐 먹지? 고민을 영원히 끝내는 법, Mealime
• • Clarity Money AI 코치: 똑똑한 소비, 부자 되는 습관을 만드는 법
• • RoomGPT AI 인테리어: 내 방 사진 한 장으로 멋진 리모델링 미리 보기

왜 지금 DDD를 배워야 할까: 소프트웨어 개발의 패러다임 전환

현대 소프트웨어 개발은 점점 더 복잡해지고 있습니다. 기업의 비즈니스 로직은 수많은 규칙과 프로세스로 얽혀 있고, 개발자들은 끊임없이 변화하는 요구사항과 씨름해야 합니다. 특히 마이크로서비스 아키텍처(Microservices Architecture)가 대세가 된 지금, 복잡한 비즈니스 도메인을 어떻게 나누고 설계할 것인가는 프로젝트 성패를 좌우하는 핵심 질문이 되었습니다.

Domain-Driven Design(DDD)은 바로 이러한 복잡성을 해결하기 위해 탄생한 소프트웨어 설계 방법론입니다. 2003년 에릭 에반스(Eric Evans)가 처음 제시한 이 개념은, 비즈니스 도메인을 중심으로 소프트웨어를 설계하자는 혁신적인 아이디어입니다. DDD는 단순히 코드를 잘 짜는 기술이 아니라, 개발자와 비즈니스 전문가가 함께 문제를 이해하고 해결책을 만들어가는 협업의 철학입니다.

Domain-Driven Design은 복잡한 비즈니스 로직을 효과적으로 소프트웨어로 구현하는 방법론입니다

 

📑 목차

1. DDD란 무엇인가: 도메인 중심 설계의 핵심
2. 전략적 설계(Strategic Design): 큰 그림 그리기
3. Event Storming: 비즈니스를 시각화하는 강력한 도구
4. 전술적 설계(Tactical Design): 실제 코드로 구현하기
5. 마이크로서비스와 DDD: 완벽한 조합
6. DDD의 실무 적용 사례와 장단점

1. DDD란 무엇인가: 도메인 중심 설계의 핵심

도메인(Domain)의 정의

도메인이란 비즈니스 영역 또는 업무의 집합을 의미합니다. 예를 들어 기업 내에서 마케팅, 구매, 연구개발, 영업 등 유사한 업무를 묶은 것이 바로 도메인입니다. 각 도메인은 고유한 비즈니스 규칙과 프로세스를 가지고 있으며, 이를 정확히 이해하는 것이 DDD의 출발점입니다.

DDD의 핵심 목표

DDD는 "Loose Coupling, High Cohesion"을 추구합니다. 즉, 시스템의 각 모듈 간 의존성은 최소화하고, 각 모듈 내부의 응집도는 최대화하는 것이 목표입니다. 이를 통해 변경에 강하고, 확장이 쉬우며, 유지보수가 용이한 소프트웨어를 만들 수 있습니다.

💡 핵심 포인트: DDD는 기술보다 비즈니스 이해를 우선시합니다. 개발자와 비즈니스 전문가가 동일한 언어로 소통하며, 도메인 지식을 코드에 직접 반영하는 것이 DDD의 본질입니다.

Ubiquitous Language (보편적 언어)

DDD의 가장 중요한 개념 중 하나는 Ubiquitous Language입니다. 이는 현업 담당자, 개발자, 디자이너 등 모든 참여자가 동일한 의미로 이해하는 공통 언어를 만드는 것입니다. 예를 들어 '마우스'라는 단어는 컴퓨터 부속품 생산 도메인에서는 '입력 장치'를 의미하지만, 해충 박멸 서비스 도메인에서는 '설치류'를 의미합니다. 명확한 의사소통을 위해 각 도메인 내에서 용어를 정확히 정의하고 사용해야 합니다.

2. 전략적 설계(Strategic Design): 큰 그림 그리기

Bounded Context (경계 지어진 컨텍스트)

Bounded Context는 비즈니스 도메인을 고유한 목적별로 경계 지은 영역입니다. 각 Bounded Context는 독립적인 모델을 가지며, 하나 이상의 마이크로서비스로 구현될 수 있습니다. 예를 들어 온라인 음식 주문 시스템에서 '주문', '주문 중계', '음식점 업무', '배달 대행'은 각각 독립적인 Bounded Context가 될 수 있습니다.

Domain Model (도메인 모델)

Domain Model은 비즈니스 도메인을 추상화한 설계도입니다. 이는 두 가지 공간으로 나뉩니다:

• Problem Space: 비즈니스 도메인을 Core Sub-Domain (핵심 도메인), Supporting Sub-Domain (지원 도메인), Generic Sub-Domain (범용 도메인)으로 분해
• Solution Space: Bounded Context 간의 관계를 나타내는 Context Map 정의

Context Map (컨텍스트 맵)

Context Map은 Bounded Context 간의 관계를 시각화한 다이어그램입니다. 주요 관계 유형은 다음과 같습니다:

• Shared Kernel: 여러 Bounded Context가 공통으로 사용하는 영역
• Upstream-Downstream: Publisher(Upstream)와 Subscriber(Downstream) 관계
• Open Host Service: 다양한 Downstream을 고려하여 설계된 Upstream
• Anti Corruption Layer: 외부 데이터를 자신에게 맞게 변환하는 계층

3. Event Storming: 비즈니스를 시각화하는 강력한 도구

Event Storming은 포스트잇을 활용해 비즈니스 프로세스를 시각화하는 워크숍 방법론입니다

 

Event Storming이란?

Event Storming은 비즈니스 도메인 내에서 일어나는 이벤트들을 찾아 Bounded Context를 식별하는 협업 워크숍 방법론입니다. 큰 벽면에 다양한 색상의 포스트잇을 붙여가며 비즈니스 프로세스를 시각화하는 이 기법은 도메인 전문가와 개발자가 함께 참여하여 효과적인 학습과 공유를 가능하게 합니다.

Event Storming 8단계 프로세스

Step 1: Domain Event 정의 (오렌지색 포스트잇)

비즈니스 도메인 내에서 발생하는 모든 이벤트를 과거형으로 기술합니다. 예: "주문이 생성되었다", "결제가 완료되었다"

Step 2: Tell the Story

도출된 이벤트로 도메인의 업무 흐름을 이해하고, 토론을 통해 누락된 이벤트를 추가합니다.

Step 3: 프로세스로 그룹핑 (보라색 포스트잇)

이벤트들을 동일한 비즈니스 주제로 그룹핑하여 프로세스를 정의합니다.

Step 4: Command 정의 (파란색 포스트잇)

각 Domain Event를 발생시키는 명령을 현재형 명령형으로 정의합니다. 예: "주문을 생성한다", "결제를 요청한다"

Step 5: Trigger 정의 (하늘색: Actor, 초록색: External System, 보라색: Policy)

Command를 일으키는 행위자와 Event를 발생시키는 외부 시스템 및 정책/규정을 정의합니다.

Step 6: Aggregate 정의 (노란색 포스트잇)

Command 수행을 위해 필요한 데이터 객체(Entity)를 정의합니다. 예: 주문, 고객, 상품

Step 7: Bounded Context 정의 (분홍색 포스트잇)

Entity, Command, Event, Actor, Policy를 고유한 비즈니스 목적별로 그룹핑하여 경계를 설정합니다.

Step 8: Context Map 작성

Bounded Context 간의 관계를 도식화하고, 동기/비동기 통신 방식을 표현합니다.

4. 전술적 설계(Tactical Design): 실제 코드로 구현하기

Layered Architecture (계층화 아키텍처)

DDD에서는 목적별로 시스템을 계층으로 나누어 설계합니다. 권장되는 계층 구조는 다음과 같습니다:

• Presentation Layer: UI 레이어 (@Controller, @RestController)
• Service Layer: Domain Layer와 Data Layer 간의 흐름 제어 (@Service)
• Domain Layer: 비즈니스 로직 처리 (@Service, @Component)
• Data Layer: 데이터베이스 CRUD 처리 (@Repository)

Entity vs Value Object

Entity는 고유한 식별자(ID)가 필요한 가변적(Mutable) 객체입니다. 예를 들어 '지폐'는 일련번호로 구별되어야 하므로 Entity입니다. 반면 Value Object는 식별자가 불필요한 불변(Immutable) 객체입니다. '50,000원'이라는 금액은 구별할 필요가 없으므로 Value Object입니다.

Aggregate와 Repository

Aggregate는 Entity들을 대표하는 추상화된 객체입니다. Entity 간 직접 통신을 피하고 Aggregate 간에만 통신하도록 설계하여 시스템의 유연성을 높입니다. Repository는 Aggregate와 Entity를 위한 데이터 접근 객체로, ORM(Object-Relational Mapping)을 사용하는 것이 이상적입니다.

5. 마이크로서비스와 DDD: 완벽한 조합

DDD의 Bounded Context 개념은 마이크로서비스 아키텍처와 자연스럽게 연결됩니다. 각 Bounded Context는 독립적인 마이크로서비스로 구현될 수 있으며, 이를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 독립적 배포: 각 서비스를 독립적으로 개발하고 배포할 수 있습니다
• 기술 다양성: 각 서비스마다 최적의 기술 스택을 선택할 수 있습니다
• 팀 자율성: 각 Bounded Context를 담당하는 팀이 자율적으로 의사결정할 수 있습니다
• 확장성: 트래픽이 많은 서비스만 선택적으로 스케일 아웃할 수 있습니다

💡 실무 팁: 비즈니스 가치가 높은 Core Domain에 집중 투자하고, Generic Domain은 외부 솔루션을 활용하는 것이 효율적입니다.

6. DDD의 실무 적용 사례와 장단점

DDD를 도입해야 하는 경우

• 복잡한 비즈니스 로직을 다루는 대규모 시스템
• 빈번한 요구사항 변경이 예상되는 프로젝트
• 마이크로서비스 아키텍처로 전환을 고려 중인 경우
• 도메인 전문가와의 긴밀한 협업이 가능한 환경

DDD의 장점

• 비즈니스 정렬: 소프트웨어가 비즈니스 요구사항을 정확히 반영
• 유지보수성: 명확한 경계와 책임으로 코드 변경이 용이
• 협업 강화: 공통 언어를 통한 효과적인 의사소통
• 확장성: 새로운 기능 추가 시 기존 시스템에 미치는 영향 최소화

DDD의 한계와 주의사항

• 학습 곡선: 개념 이해와 적용에 상당한 시간 투자 필요
• 초기 비용: Event Storming과 모델링에 많은 시간 소요
• 과도한 복잡성: 단순한 CRUD 애플리케이션에는 오버엔지니어링
• 도메인 전문가 필요: 비즈니스 전문가의 적극적인 참여가 필수

⚠️ 주의: DDD가 필요하지 않은 경우

단순한 게시판이나 소규모 웹사이트처럼 비즈니스 로직이 단순한 프로젝트에서는 DDD를 적용하지 않는 것이 좋습니다. 오히려 개발 속도를 늦추고 불필요한 복잡성만 추가할 수 있습니다.

DDD 학습을 위한 추천 리소스

📚 추천 도서

• Domain-Driven Design by Eric Evans (원서)
• 도메인 주도 설계 핵심 by Vaughn Vernon (한국어 번역서)
• 마이크로서비스 패턴 by Chris Richardson

🌐 공식 커뮤니티

DDD Community 공식 사이트 바로가기 →

DDD 창시자 Eric Evans의 공식 커뮤니티로, 최신 자료와 베스트 프랙티스를 확인할 수 있습니다.

❓ 자주 묻는 질문 (FAQ)

Q1. DDD를 배우려면 어떤 기술적 배경이 필요한가요?

객체지향 프로그래밍에 대한 기본적인 이해가 있다면 충분합니다. Java, C#, Python 등 객체지향 언어를 다룰 수 있고, 클래스와 인터페이스 개념을 알고 있다면 DDD 학습을 시작할 수 있습니다.

Q2. Event Storming 워크숍은 얼마나 자주 해야 하나요?

프로젝트 초기에는 전체 도메인을 파악하기 위한 Big Picture Event Storming을 진행하고, 이후에는 새로운 기능 개발이나 주요 변경 사항이 있을 때마다 필요한 부분만 선택적으로 진행하는 것이 효율적입니다.

Q3. Bounded Context를 나누는 기준은 무엇인가요?

비즈니스 목적, 데이터 일관성 요구사항, 팀 구조, 변경 주기 등을 종합적으로 고려해야 합니다. 일반적으로 다른 속도로 변경되거나, 다른 팀이 담당하거나, 다른 데이터베이스를 사용해야 하는 영역은 별도의 Bounded Context로 분리하는 것이 좋습니다.

Q4. 기존 모놀리식 시스템에 DDD를 적용할 수 있나요?

가능합니다. 전체 시스템을 한 번에 바꾸는 대신, 새로운 기능을 DDD 원칙에 따라 개발하거나, 변경이 잦은 핵심 모듈부터 점진적으로 리팩토링하는 Strangler Fig 패턴을 적용할 수 있습니다.

Q5. DDD와 애자일 방법론은 함께 사용할 수 있나요?

오히려 DDD는 애자일과 매우 잘 어울립니다. Event Storming을 통한 빠른 프로토타이핑, 반복적인 모델 개선, 비즈니스와의 긴밀한 협업 등 DDD의 핵심 원칙은 애자일의 가치와 일치합니다.

마무리: DDD로 시작하는 더 나은 소프트웨어 설계

Domain-Driven Design은 단순한 설계 기법을 넘어, 비즈니스와 기술을 연결하는 다리 역할을 합니다. Event Storming을 통해 도메인 전문가와 개발자가 동일한 언어로 소통하고, Bounded Context로 복잡한 시스템을 관리 가능한 단위로 나누며, 계층화된 아키텍처로 변경에 강한 코드를 작성할 수 있습니다.

특히 마이크로서비스 시대를 맞아 DDD의 중요성은 더욱 커지고 있습니다. 복잡한 비즈니스 요구사항을 명확히 이해하고, 이를 유지보수 가능한 소프트웨어로 구현하고자 한다면, DDD는 반드시 학습해야 할 필수 방법론입니다. 지금 바로 Event Storming 워크숍을 계획하고, 팀과 함께 도메인을 탐험하는 여정을 시작해보세요.

🚀 DDD 실무 적용을 위한 다음 단계

작은 프로젝트부터 시작하여 Event Storming을 직접 경험해보세요. 완벽하지 않아도 괜찮습니다. 도메인 모델은 반복적으로 개선되는 것이니까요!