현장에서 통하는 도메인 주도 설계 실전 가이드

현장에서 통하는 도메인 주도 설계 실전 가이드 - 개발자 관점에서 설명한 실무에 강한 DDD 입문서!
마스다 토오루 외 지음, 이승환 옮김 / 길벗 / 2025년 8월

개발을 하다 보면 자주 하는 고민이 있습니다. ​ 왜 기능은 잘 구현했는데, 시간이 지날수록 코드가 복잡해지고 관리가 힘들어질까? ​ 또한 프로젝트 초기에는 깔끔했는데, 어느 순간 비즈니스 로직이 뒤엉켜버린 건 왜일까? ​ 이런 문제는 시간이 부족해서 도메인 지식이 없어서 일 수도 있습니다. ​ 하지만 진짜 이유는 따로 있습니다. 바로 비즈니스를 코드로 제대로 녹여내지 못했기 때문이죠. ​ 현대의 소프트웨어 개발은 기본적이 구현(CRUD)을 넘어 도메인(비즈니스 본질)을 정확하게 이해하고 이를 코드에 담아내는 것이 핵심 경쟁력이 필요합니다. ​ 이를 도와줄 책이 나왔습니다. 바로 '현장에서 통하는 도메인 주도 설계 실전 가이드' 책 인데요. 이름 그대로 이 개념을 실제 프로젝트 현장에서 바 로 써먹을 수 있도록 풀어낸 책입니다. ​ 이 책에 대해서 자세히 알아보도록 하겠습니다.

1) 도메인 주도 개발이란?

DDD는 에릭 에반스(Eric Evans)가 제시한 소프트웨어 개발 방법론으로 비즈니스의 본질(도메인)을 중심에 두고 소프트웨어를 설계·구현하는 것입니다. ​ 일반적으로 기획서의 요구사항을 개발자가 코드 작성으로 끝나는 게 아니라, 비즈니스 전문가(도메인 전문가)와 개발자가 함께 협력해 문제를 정의하고, 그 문제를 정확히 모델링하여 코드로 옮기는 접근 방식입니다. ​ 현장에서 통하는 도메인 주도 설계 실전 가이드 책은 도메인 주도 설계의 기본 개념을 이해하면 각 패턴의 목적과 사용법이 명확해진다고 하는데요. 기초가 되는 이론을 정확하게 이해하는 중요 하다는 것을 알 수 있습니다. 특히 실제 코드 파일이 기존에 비해 상당히 많아지기 때문입니다. ​ 파일이 많아 진다고해서 복잡 하기 보다는 책임과 역할이 분리가 되면서 어느 부분을 유지보수를 하면 되는지 알기 때문에 접근성은 더 좋아진다고 볼 수 있습니다.

2) 프런트, 백엔드가 다른 회사라면

현장에서 통하는 도메인 주도 설계 실전 가이드 책은 실제 현업에서 있었던 DDD 적용 사례를 알려주는데요. 기억에 남는 프로젝트는 고객사, X사(프런트 엔드팀), Y사(백엔드 팀) 구성이 된 케이스였습니다. 이 구조에서 문제점은 프론트엔드 팀과 백엔드팀의 용어와 사양이 서로 맞지 않아 일관성이 없었다고 합니다. ​ 또한 업무에 대한 인식이 서로 달라 개발 우선순위 진행 방식도 합의가 되지 않았죠. 이러한 문제점을 인지하고 DDD 기반으로 변경합니다. 가장 먼저 경계 컨텍스트 단위로 팀이 구성 돼 하나의 도메인 모델을 공유하고 용어나 설계를 공유하는 구조로 바꿉니다. ​ 구조를 바꾼 이후 업무 단위로 팀간 정보의 공유 및 통제가 과제로 남게 되는데요. 업무간 인터페이스가 필요 하게 되면 어느 업무팀에서 명세의 결정권을 가질 것이며 어떻게 진행할지 논의를 나눕니다. 한편 이와 같이 IT 국내 기업들도 소 조직 단위로 나뉘어서 일하고 있습니다.

이 포스팅은 길벗 출판사에서 책을 받아 주관적으로 작성했습니다.