[리뷰] 현장에서 통하는 도메인 주도 설계 실전 가이드
in Review on Review, Book, 도메인, 설계, 실전, Ddd, 모델, 아키텍처, 패턴, 유비쿼터스언어, 이벤트, Solid, Ai, 클린아키텍처, 응용프로그램, 모바일
길벗출판사의"현장에서 통하는 도메인 주도 설계 실전 가이드(마스다 토오루, 타나카 히사테루, 오쿠자와 토시키, 나카무라 아츠시, 나루세 마사노부 저 외 2명)"를 읽고 작성한 리뷰입니다.
기존 도메인 주도 설계(DDD)의 추상성에 저자의 구체화된 실전 사례, 클린 아키텍처, 마이크로서비스 아키텍처(MSA), 협업, 현대적 관점까지 총망라한 실전 중심의 도메인 주도 설계 가이드
설계라는 주제를 다루는 책은 언제나 그렇듯 추상적이다. 뛰어난 품질의 S/W 작성을 견인하는 오케스트레이터임에도 불구하고 유일한 맹점은 모호한 추상성에 있는 것 같다. 이 모호함을 해소할 수 있는 가장 좋은 방법이 실전 사례로 설명하는 것인데 이 부분이 책의 가장 돋보이는 장점이다.
도메인 주도 설계(DDD)는 일찍이 Eric Evans가 2003년에 제시하였고 그의 명저가 있음에도 갈증은 여전했다. 이유는 두가지로 나뉜다. 하나는 앞서 이야기한 추상성의 문제였고, 다른 하나는 세월이 흘렀다는 점이다. 본 도서에도 언급했듯 객체지향의 대표 언어인 JAVA에는 오늘날 함수형 기법이 도입되기 시작했고 DDD가 다시 각광받은 커다란 계기인 마이크로서비스 아키텍처(MSA)나 클린 아키텍처의 개념이 등장했다.
누군가 이들을 포괄적으로 아울러 도메인 주도 설계를 재해석해주길 바랬는데 때마침 이 책이 등장해서 얼마나 반가웠는지 모른다.
또한, 여기서 그치지 않는다. AI가 등장하며 그동안 추상성으로 외면해왔던 설계 관련 지식들의 필요성이 더욱 중요해졌다. 바이브 코딩 도구의 대표주자는 커서만 놓고 보아도 Rules 선언의 중요성은 두말할 나위없다. SOLID, 클린아키텍처, MSA, DDD 등은 이미 AI가 잘 알고 있는 영역이기에 Rules에 프롬프팅만 해줘도 설계 품질의 차원이 달라진다. 여러 시대적인 흐름이 맞물려 시의적절하게 등장했으니 참 고마운 일이다.
포괄적인 소개에 이어 책 내용 중 몇가지 인상깊었던 점을 추려보면 다음과 같다. 책의 초반부에는 적재 및 운송 분야의 업무 사례인 오버부킹 지식을 사례로 DDD의 개념을 풀어나간다.
실무에서 도메인 모델을 제대로 만들려면 업무담당자, 시스템 유지보수자, 실제 운영코드, 유사 시스템 경험자 등, 다양한 소스로부터 규칙과 맥락을 통합해야 한다는 사실을 잘 강조하는 그림으로 단순히 한 사람이나 한 문서만 참고하면 도메인의 본질을 놓치기 쉽다는 점을 보여주는 좋은 예시이다. 
도메인 모델의 핵심을 중심으로 사용자 인터페이스, 테스트, 로그, 시스템 관리, 웹 API, 메시지, 데이터베이스, 파일 등 다양한 포트와 어댑터가 연결되는 헥사고날 아키텍처도 주목할만한 부분이다. DDD는 도메인 모델이 소프트웨어의 중심이 되도록 아키텍처를 설계하며, 외부 세부 사항과의 연결은 포트/어댑터를 통해 관심사를 분리하는 것이 특징이다. 
이어 아래 그림에서 볼 수 있듯 풀 오더 영역은 경쟁 우위를 창출하는 업무 영역인데 프로젝트의 복잡성과 업무 성격에 따라 개발 방식을 다르게 적용해야 함을 보여준다. 단순한 업무는 표준화된 방식으로 충분하고, 완제품 개발이나 독립적인 업무는 별도 접근이 적합함을 알 수 있다. 이처럼 DDD는 복잡한 도메인 문제를 해결해준다. 
저자의 경험 중 재미있는 사례가 있다. 우리가 일상에 늘 흔히 겪는 일이기도 하다. 아래 그림은 복잡한 비즈니스 프로젝트에서 다양한 이해관계자(고객, 경영진, 사업 담당자, 정보 시스템 담당자) 간의 요구사항, 목표, 업무 기준이 상이하며 프런트엔드와 백엔드 개발팀이 역할과 기술적 해결 방식을 달리하는 현실을 보여준다. 
결국 각팀이 서로 협업하며 모델을 공유·정제하고, 명확히 경계를 나누는 것이 중요함을 알 수 있다. 
여기서 말하는 유비쿼터스 언어가 무엇인지 아래 예시가 잘 설명하고 있다. 핵심 도메인 용어(예: Review, Document, Alert)를 표(Table)와 다이어그램으로 정리하여 모두가 쉽게 참조할 수 있게 만들고, 용어 간 관계를 명확히 시각적으로 파악하게 한다면 중복, 오용, 소통 오류를 줄일 수 있다. 
이벤트 스토밍 다이어그램 또한 눈여겨 볼 부분이다. 비즈니스 이벤트의 흐름(카드 결제, 송금 등 비즈니스 프로세스)을 이벤트 스토밍 다이어그램으로 표현한 예시인데 복잡한 비즈니스 로직과 데이터 흐름을 시각적으로 공유함으로써, 현업과 개발자 모두가 ‘동일 모델, 동일 언어’로 시스템을 바라보게 만드는 효과를 얻을 수 있다. 
3부에서는 클린 아키텍처와의 결합을 시도한다. 비즈니스 도메인의 규칙과 모델을 아키텍처 중심에 두고, 외부 기술 요소와 명확하게 분리하여 설계하는 것이 DDD와 클린 아키텍처 모두의 핵심이다. 이러한 구조는 변화에 강하고, 도메인 모델의 순수성과 유연성을 보장한다는 장점을 취할 수 있다. 
보다 구체적인 연결 고리는 아래 아키텍처를 통해 확인할 수 있다. 비즈니스 규칙이 우선되고 의존성 주입 분리 및 계층 분리가 명확하게 이뤄짐을 볼 수 있는 예시이다. 
정리하자면, 기존 DDD 이론서의 추상성을 실무의 언어와 다이어그램, 실제 협업 구조, 현장 인터뷰 및 업무 절차까지 총망라한다. 높은 추상성의 벽에 막혀 실전 DDD 프로젝트를 수행하는 데 애를 먹었던 독자라면 저자의 실전 사례를 따라가며 상당 부분 애로사항을 해결 할 수 있을 것 같다. DDD를 보다 실무 중심으로 이해하고 싶은 모든 독자에게 추천하고 싶다.
