DDD에 대해서 간단하게 정리하기

도메인 주도 설계에 관심이 있어서 [NHN FORWARD 22] DDD 뭣이 중헌디? 🧐 를 보았는데,

해당 영상만 보고는 쉽게 이해가 가지 않아 여러 영상들과 글들을 참고 해서 얕게나마 정리 해보았습니다.

 

정리 해두고 다음에 다시 보고 더 정리 해 봐야겠습니다.

 

---

DDD (Domain-Driven Design)

도메인이란 무엇인가?

먼저, 도메인이란 특정 정보와 활동이 이루어지는 영역을 의미합니다. 프로그래머에게 도메인은 애플리케이션의 로직이 관여하는 정보와 활동의 영역을 나타냅니다. 예를 들어, "회원"이라는 도메인에서는 회원 가입, 탈퇴와 같은 회원과 관련된 일련의 작업들이 포함됩니다.

 

또한, "도메인 레이어"와 "도메인 로직"이라는 용어는 비즈니스 로직과 동일한 개념으로 받아들여집니다. 이 비즈니스 로직은 특정 모델 데이터를 생성하거나 변경하기 위해 도메인 내 주체들이 지켜야 할 규칙을 정의합니다.

 

DDD (Domain-Driven Design)란 무엇인가?

도메인 주도 설계(DDD)란 소프트웨어 개발에서 도메인을 중심으로 설계를 진행하는 방식을 의미합니다. 이 설계 접근법은 복잡한 애플리케이션을 보다 쉽게 관리하고 진화시킬 수 있도록 각 도메인을 독립적으로 설계하여 높은 응집력과 낮은 결합력을 유지하는 것을 목표로 합니다.

 

DDD의 세 가지 주요 원리

1. 핵심 도메인과 그 기능에 집중하라.
2. 도메인의 모델의 정교하게 구축하라.
3. 어플리케이션 모델을 발전시키고 새롭게 생기는 도메인 관련 이슈를 해결하기 위해 도메인 전문가와 끊임없이 협력하라.

 

DDD의 목표: 소프트웨어를 통해 중요한 문제를 해결하는 것

DDD에서 가장 중요한 목표는 단순히 좋은 설계를 넘어, 소프트웨어를 통해 도메인 내 중요한 문제를 해결하는 것입니다. 

 

기존 시스템과의 통합: 현실적 설계의 중요성

많은 경우 DDD는 새로운 소프트웨어를 설계하기보다는, 이미 존재하는 소프트웨어와 연동과 통합을 고려하여 확장해야 하는 상황에서 더욱 필요합니다. 예를 들어, 물류 시스템에서는 출발지와 도착지를 기반으로 최적 경로를 계산하는 작업을 기존 시스템에서 수행할 수 있습니다. 새로운 시스템을 구축할 때 이와의 상호작용을 고려하지 않으면 프로젝트는 실패할 가능성이 큽니다.

 

DDD의 본질: 전략적 설계 vs. 전술적 설계

 

DDD의 두 가지 핵심 접근법 중 하나는 전략적 설계(Strategic Design)입니다. DDD에서 전략적 설계는 소프트웨어를 구성하는 각 요소의 컨텍스트(Context)를 이해하고 이를 기준으로 설계하는 것을 말합니다. 컨텍스트란 특정 상황에서 개체가 처해 있는 환경을 의미합니다. 예를 들어, "피자"라는 개념은 가게의 접시에 놓였을 때와 길거리에 버려졌을 때 다른 의미를 가집니다. 이처럼 같은 객체라도 상황에 따라 의미가 달라질 수 있음을 고려하여 설계하는 것이 전략적 설계의 핵심입니다.

 

전술적 설계는 코딩 단계에서의 구체적인 기술적 패턴에 집중합니다. 예를 들어, 특정 바운디드 컨텍스트 내에서의 이벤트 추적을 통해 문제를 해결하는 방식입니다. 이와 같이, 전술적 설계는 특정 문제 영역을 해결하는 데 유리하며, DDD의 핵심 원칙에 따라 중요한 도메인에서만 사용합니다.

 

DDD 설계 단계: 주택 설계를 통한 비유

DDD의 설계 과정을 주택 설계로 비유해 보겠습니다.

1. 주택의 핵심 가치 선정: 수영장 크기, 헛간 공간 등 주택의 중요한 요소를 결정합니다.
2. 기존 주택 조사: 기존에 지어진 주택을 참고하여 원하는 집의 형상을 구상합니다.
3. 모델링 및 설계: 주택의 구체적인 설계도를 작성하여 각 공간을 세밀하게 정의합니다.

이 과정에서 DDD의 다양한 용어가 사용됩니다.

• Domain (도메인): 주택 전체를 아우르는 설계 전체를 의미합니다.
• Subdomain (하위 도메인): 헛간, 수영장, 화장실, 안방 등과 같은 주택을 구성하는 각 부분입니다.
• Bounded Context: 각 하위 도메인의 구체적인 상황(문맥적 상황)을 정의하는 영역입니다. 예를 들어 주택 정문에서 일하는 사람은 '경비원'을 뜻하겠지만, 주택 건물 안에서 일하는 사람의 경우 '아이를 돌보는 사람'이 될 수 있습니다.
• Domain Model (도메인 모델): 주택의 설계를 구체화한 모델로, 각 하위 도메인의 실제 형상을 나타냅니다.

 

도메인 전문가와 개발자의 소통을 위한 유비쿼터스 언어

유비쿼터스 언어는 도메인 전문가와 개발자가 공통으로 사용하는 언어로, 코드, 문서, 대화 등 모든 의사소통에서 일관되게 사용됩니다. 이를 통해 도메인 지식을 정확하게 소프트웨어에 반영할 수 있습니다. 예를 들어 주택 설계에서 거실, 욕실, 안방 같은 용어는 집 제작자와 건축업자 모두가 이해할 수 있는 공통된 어휘로 사용됩니다. 이를 유비쿼터스 언어라고 하며, 실제 개발에서도 기획자, 디자이너, 개발자 모두가 이러한 공통된 언어를 사용함으로써 서로 간의 이해 차이를 줄일 수 있습니다.

 

DDD를 통한 협업과 구현 방식

DDD는 도메인 전문가와 개발자의 원활한 협업을 중시하며, 이를 위해 Event Storming과 같은 전략적 디자인 툴을 사용합니다. Event Storming은 도메인 모델을 구성하는 주요 이벤트를 시간 순서대로 나열하여 도메인 전문가와 개발자가 함께 도메인 지식을 쌓는 과정입니다. 다음은 Event Storming의 진행 단계입니다.

1. 미팅: 도메인 전문가와 개발자가 모여 도메인에 대한 질문을 주고받습니다.
2. 이벤트 나열: 주요 이벤트를 시간 순서대로 나열하고, 색상별로 이벤트, 명령어, 정책 등을 분류하여 포스트잇에 적어 붙입니다.
3. Bounded Context 찾기: 나열된 이벤트를 바탕으로 Catalog, Payments, Delivery 등 subdomain을 분리하여 각 Bounded Context를 정의합니다.

 

컨텍스트 맵과 맵핑 관계

 

컨텍스트 맵은 각 바운디드 컨텍스트 간의 관계와 의존성을 시각화하여 표현한 다이어그램입니다. 예를 들어, 물류 시스템의 경우 '운송 컨텍스트'와 '운임 계산 컨텍스트' 간의 관계를 나타내어 서로의 상호작용을 시각적으로 표현할 수 있습니다. 이를 통해 팀은 도메인 내에서의 관계를 보다 쉽게 파악하고, 문제를 효과적으로 해결할 수 있는 방법을 모색할 수 있습니다.

 

바운디드 컨텍스트는 특정 도메인 모델이 적용되는 명확한 경계를 의미합니다. 각 바운디드 컨텍스트 내에서는 용어와 개념이 일관성 있게 사용됩니다. 서로 다른 바운디드 컨텍스트 간에는 컨텍스트 맵을 통해 관계를 정의합니다.

 

요약

DDD는 도메인을 중심으로 복잡한 문제를 해결하는 강력한 설계 철학입니다. 주요 개념을 요약하자면 다음과 같습니다.

1. 핵심 도메인에 집중: 소프트웨어의 주요 가치를 창출하는 핵심 도메인에 집중하여 리소스를 투자합니다.
2. Ubiquitous Language 사용: 팀 전체가 공유하는 공통 언어로 도메인 지식을 효과적으로 전달합니다.
3. Bounded Context로 도메인 분리: 특정 도메인의 상황에 맞게 분리된 환경을 정의하여 각 요소가 독립적으로 관리되도록 합니다.
4. Event Storming을 통한 협업: 도메인 전문가와 개발자가 이벤트 중심으로 협업하여 도메인 모델을 형성합니다.

---

 

DDD는 상대적으로 단순한 소프트웨어나 비즈니스 도메인 요소가 약한 서비스에는 적합하지 않은 설계 기법이라고 합니다.

아직 대규모 서비스 설계 경험이 없어서인지, 어휘도 어렵고 이해하기 쉽지 않은 부분이 꽤 있었습니다.

몇 권의 설계 관련 서적을 더 읽은 후 다시 살펴보면 더 잘 이해할 수 있을 것 같아, 아직 완전히 이해하지 못한 부분이지만 정리해 보게 되었습니다...

다음에 다시 돌아오겠습니다 🫡

---

참고

- [NHN FORWARD 22] DDD 뭣이 중헌디? 🧐

- Domain Driven Design 이란 무엇인가?

- [우아콘 2021] 도메인 원정대

- What is DDD - Eric Evans - DDD Europe 2019

- https://blog.naver.com/PostView.naver?blogId=seek316&logNo=222710251462