DDD(도메인 주도 개발) 이란? 그리고 실제 적용한 사례

DDD(도메인 주도 개발) 이란?

DDD(도메인 주도 설계)는 소프트웨어 시스템을 개발할 때 도메인(업무 영역 또는 비즈니스 영역)을 중심으로 설계하는 소프트웨어 개발 방법론입니다. 이 방법론은 복잡한 시스템을 이해하고 관리하기 쉽도록 도메인과 관련된 지식을 효과적으로 모델링하고 사용하는 방법을 제공하죠. 

 

실제 MSA 전환 작업을 하면서 DDD를 적용

현재 차세대 프로젝트를 맡으면서 레가시 시스템을 MSA 아키텍처로 변환하는 중에 이 DDD 방법론을 써서 아키텍처 및 프로젝트 구조를 리뉴얼 하는 중인데요. 이것 때문에 정말 미친 듯이 바쁘고 힘든 나날을 보냈습니다ㅠ (특히 읽혀지지도 않는 레가시 코드는 정말 건강에 해롭습니다)

 

DDD는 1년 반 쯤 전에 접했을 때는 조금 생소한 개념이었습니다. 그때 최범균님의 도메인 주도 개발이라는 책을 한 4번 쯤 읽고 여러 외국 포스팅이나 MSA와 연관지어 보니 어떻게 적용해야 될 지 윤곽이 보였습니다.

 

직접 적용해보면서 느꼈던 점은 다음과 같습니다.

 

1. Event storming은 구성원이 DDD와 MSA에 대한 이해가 제대로 되어 있는 구성원이 모여서 해야 한다. 만약 그렇지 못할 경우 서로 커뮤니케이션에 대한 비용만 들어 애꿋은 시간만 낭비할 가능성이 높음.
2. 공통 언어(Ubiquitous language)는 도메인 전문가의 말을 우선적으로 따라야 한다. 이것까지는 당연하지만 프로젝트와 클래스명을 구성할 때도 공통 언어에서 쓰는 명칭을 기준으로 클래스와 메서드, 멤버 변수명을 꼭 작성하는 것이 좋다. 
3. DDD의 핵심은 Domain와 그 Aggregate를 어떻게 나눌 것인가가 핵심이라고 생각. 잘못 나눴을 경우 로직이 복잡해 지고 의존성이 오히려 꼬이게 되는 사태가 일어날 수 있다. 하지만 잘 나눴을 경우 프로젝트 구조가 명확해지고 각 Aggregate의 역할과 의존성 파악이 명확해줘서 유지보수하기 쉬운 코드가 생성된다. 
4. 자칫하면 Aggregate에 도메인 로직에 필요한 멤버 변수와 메서드가 집중되어 클래스가 굉장히 비대해질 수 있다. 단일 책임 원칙이라고 할 수 는 있는데 코드량이 한 클래스에 집중되어 가독성과 유지보수가 급격하게 떨어지는 경험을 많이 했음. 그에 대한 대안으로 도메인 로직이 복잡한 경우 각각의 서브 도메인 로직에 해당하는 domain service를 두는 것이 유지보수 하는 데 경험적으로 굉장히 좋았다.
5. MSA는 Aggregate를 잘 나눴을 경우 MSA를 어떻게 나눌 것인지 의사결정하기 굉장히 수월해진다. Aggregate의 집합인 Bounded Context가 결국 MSA의 단위가 되므로 팀 구성원들과 합을 맞추어 서비스를 나누기가 편한 함

이 밖에도 여러 가지가 있는 데 생각날 때마다 추가적으로 공유하도록 하겠습니다.

 

차세대 프로젝트의 DDD 실천 방법론 및 주의 사항

그리고 보통 DDD의 첫 번째 과정은 Event storming이라는 과정을 거치게 되는 데 차세대 프로젝트를 할 시에는 이 과정이 어떻게 보면 불필요한 과정일 수 있습니다. 차라리 아키텍처들과 도메인 전문가가 서로 협업하여 요구사항을 확실하게 정리해 나가고 그에 따라 프로젝트 구성 및 개발 테스트 검증, 수정 과정을 계속해서 돌리는 것이 오히려 일처리가 더 빠르게 진행됬었습니다. 만일 도메인 전문가(IT운영자) 들과 MSA를 나누자고 서비스를 먼저 나누는 시도를 했다가는 그 부분에 대해 모르는 사람들이 앉아서 실효성 없는 문서만 작성하다가 시간만 낭비할 가능성이 굉장히 높습니다. (저같은 경우 매니저가 그런식으로 일을 진행했다가 애꿎은 1개월만 별 소득 없이 시간만 날렸던 기억이 있습니다.)

 

차세대 프로젝트로 레가시 프로젝트를 MSA로 전환할 시에는 보통 도메인 지식과 MSA 시스템 디자인이 가능한 개발 실력이 출중한 사람이 있다면 금상첨화겠지만 보통은 둘 중 하나의 역량을 가진 경우가 많습니다. 이럴 때 고려했던 방안은 도메인 전문가가 시스템 아키텍트와 계속해서 커뮤니케이션 하면서 요구사항을 정립하는 방향으로 진행했습니다. 물론 100% 요구사항이 정리가 될 수가 없기에 요구사항이 리스팅 될 때마다 애자일 프로세스(디자인 -> 개발 ->  테스트 -> 검증 -> 피드백 -> 수정)을 계속해서 돌려가며 하나하나 퍼즐을 맞춰가듯이 프로젝트를 구축해 갔습니다.

 

다음에 시간이 있을 때는 어떻게 요구사항을 반영하여 DDD 방법론을 가지고 프로젝트를 구현해 나갔는 지에 대해서 구체적으로 포스팅 하도록 하겠습니다.

 

Reference

https://microservices.io/articles/index.html