[TIL 23] DDD 이해하기

 Today I Learned

도메인 주도 설계: Domain Driven Design(DDD) 특강을 들으며 기존에 공부했던 Layered Architecture Patten과 유사하다는 생각이 들었다. 🤔 음.. 굳이 차이점이 있다면 Layered Architecture Patten은 계층 분리에 집중을 했다면, DDD는
Layered Architecture Patten을 적용하지만, 유사한 도메인의 집합들을 어떻게 나눌지에 조금 더 초점을 맞추는 느낌이었다. 아직 DDD의 개념을 100프로 이해하지 못하여 추후에 DDD 설계 관련 서적을 구입하여 공부할 때 오늘의 기록이 밑거름이 될 수 있도록 DDD 맛보기 느낌으로 이해한 만큼만 복습해 보려고 한다.

---

[ DDD 등장 배경 ]

과거에는 주로 기술 중심의 개발 방법론이 사용되었기 때문입니다. 이러한 방법론은 기술적 요구사항을 중점적으로 다루지만, 비즈니스 측면에서 발생하는 다양한 요구사항을 효과적으로 반영하기에는 한계가 있었습니다. 특히, 비즈니스 전문가와 개발자 간의 소통이 원활하지 않으면, 최종 소프트웨어가 비즈니스의 실제 요구를 충족시키지 못할 수 있었습니다.
💁 이러한 문제점들을 해결하기 위해 나온 설계가 도메인 주도 설계: Domain Driven Design(DDD)입니다

---

• DDD에서 말하는 Domain 이란?
  • 유사한 업무의 집합인 비즈니스 Domain을 의미합니다.
  • 소프트웨어 개발의 중심을 비즈니스 도메인에 집중
  • 소프트웨어로 해결하려는 문제의 영역을 의미

---

[ DDD 핵심 가치 ]

도메인 주도 설계의 저자 에릭 에반스는 언어의 중요성을 강조하며 유비쿼터스 언어(Ubiquitous Language) 라는 용어를 사용했습니다. 이 개념은 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들어, 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 동일하게 사용하는 것을 의미합니다.

DDD는 소프트웨어 개발에서 도메인 지식이 가장 중요한 요소임을 인식하고, 이를 중심으로 소프트웨어를 설계합니다.
도메인 전문가와 개발자가 협력하여 도메인 모델을 구축하고, 이를 통해 비즈니스 요구사항을 충실히 반영할 수 있습니다. 이렇게 하면 복잡한 소프트웨어 시스템도 효과적으로 관리할 수 있게 됩니다.

결국, 도메인 전문가, 이해관계자, 그리고 개발자가 동일한 지식을 공유하고 직접 소통하여 비즈니스와 기술 간의 간극을 좁히고, 복잡한 시스템에서 발생할 수 있는 문제들을 효과적으로 해결하는 것에 목적을 두고 있습니다

---

[ DDD의 구조 1 ]

MSA 개념 분리와 DDD 도메인 분리

• 왼쪽 도메인 설계도의 문제점
  
  • 왼편과 같은 그림의 도메인 모델을 구성했을 때 어떤 도메인 모델이 어떤 역할을 하는지 쉽게 판단이 되지 않습니다.
  • 이처럼 개별 객체 단위에서 상위 객체의 개념을 파악하려면 오랜 시간이 걸립니다. 
  • 주요 도메인 개념 간의 관계를 파악하기 어렵다는 것은 곧 코드를 변경하고 확장하는 것이 어려워진다는 것을 의미합니다.
• 애그리거트 (Aggregate)
  • 애그리거트란 관련된 객체들을 모아 하나의 단위로 취급하는 개념
  • 오른쪽 그림과 같이 연관 도메인을 애그리거트로 묶어 하나의 군집으로 이해한다면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있습니다.
  • 애그리거트는 특정 도메인 군집에 속한 객체들을 관리하는 ‘루트 엔티티’ 를 가지고 있습니다.
  • 하나의 애그리거트에는 ‘반드시 하나의 루트 엔티티’가 존재합니다.
  • 루트 애그리거트를 통해 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근할 수 있습니다.

---

[ DDD의 구조 2 ]

• DDD도 Layered Architecture 와 같이 표현, 응용, 도메인, 인프라스트럭처 4개의 계층으로 이루어져 있습니다.
• 고수준 모듈이 저수준 모듈에 의존하지 않는 구조로 개발이 필요합니다.
• 만약 불가피하게 응용 계층(Application)에서 인프라스트럭처의 코드를 사용 할 경우 의존역전원칙(DIP) 을 이용하여 하위 계층에 의존하지 않는 형태로 개발해야 합니다.
  • DIP(Dependency Inversion Principle): 상위 모듈은 하위 모듈에 의존하지 않아야 한다.

---

[ MSA 에서의 DDD ]

MSA 개념 분리와 DDD 도메인 분리

🤔 일부 사람들은 MSA가 보편화되면서 DDD가 주목받게 되었다고 합니다. 그렇다면 왜 MSA에서 DDD가 부각되었을까요?
💁그것은 모놀리식 애플리케이션을 MSA로 전환하는 과정에서 서비스를 식별하고 분석 및 설계하는데 DDD가 큰 도움을 주기 때문입니다. 추가로 복잡한 비즈니스 로직이나 모놀리식 애플리케이션을 MSA로 전환할 때, 가장 중요한 것은 서비스의 경계를 명확히 나누는 것입니다. 따라서 MSA와 DDD를 함께 사용하면, 도메인 경계를 기반으로 각 도메인에 해당하는 마이크로서비스를 정의할 수 있습니다.

---

오늘은 도메인 주도 설계: Domain Driven Design(DDD) 에 대하여 큰 틀을 알아보았다. 지금은 더 깊게 이해하면 오히려 헷갈릴 수도 있을 거라는 생각이 든다. 추후에 서적을 구매하여 조금 더 깊이 있게 공부해 보도록 하자!

 

읽어주셔서 감사합니다 😊