[독서] 도메인 주도 설계

에릭 에반스의, "도메인 주도 설계: 소프트웨어의 복잡성을 다루는 지혜"를 처음 손에 잡은 지 1년이 훌쩍 넘었고, 어느덧 5회독을 마쳤습니다. 처음 이 책을 접했을 때의 저는 유튜브나 세미나 영상에서 얻은 단편적인 정보들로 인해 DDD를 마치 정답이 있는 디자인 패턴 모음집이나 특정 기술 스택처럼 이해하고 있었죠. 하지만 회독을 거듭하고, 실제 업무 현장에서 치열하게 고민하며 경험을 쌓을수록 이 책은 사고방식과 실천 전략을 제시하며, 에릭 에반스가 진정으로 말하고자 했던 '지혜'의 의미를 조금씩 깨닫기 시작했습니다.

---

DDD, 정답이 아닌 '탐구의 여정' 

초기에는 저처럼 많은 분들이 DDD를 애그리거트, 리포지토리, 팩토리와 같은 특정 '패턴'의 적용으로만 생각하기 쉽습니다. 마치 잘 만들어진 레고 블록처럼 가져다 쓰면 모든 문제가 해결될 것이라는 막연한 기대감도 있었죠. 하지만 2회독, 3회독을 넘어가면서, 책의 행간에 숨겨진 저자의 메시지에 귀 기울이게 됩니다. DDD는 단순히 패턴을 나열하는 기술서가 아니라, 복잡한 비즈니스 도메인을 소프트웨어로 효과적으로 표현하고 관리하기 위한 사고방식과 접근 방식에 대한 심도 깊은 통찰을 담고 있습니다.

특히 3부 '모델의 정제'와 4부 '전략적 설계'에 이르러서는 "아, 에릭 에반스가 말하는 건 결국 '방향성'이구나" 하는 깨달음을 얻었습니다. 그는 "모든 프로젝트는 도메인 전문가의 통찰력을 포착하는 모델을 통해 더 나은 결과를 얻을 수 있다"고 강조합니다. 이는 단순히 코드를 잘 짜는 것을 넘어, 소프트웨어가 해결하고자 하는 근본적인 업무 문제를 깊이 이해하고, 그 이해를 바탕으로 비즈니스 전문가와 유비쿼터스 언어로 소통하며, 끊임없이 모델을 다듬어가는 과정의 중요성을 역설하는 것이었습니다. 실제 업무에서 비즈니스 요구사항이 시시각각 변하고, 팀원들 간의 용어 혼란으로 의사소통에 장애가 생겼을 때, "아! 이것이 유비쿼터스 언어의 부재로 인한 문제구나" 하고 무릎을 탁 쳤던 기억이 생생합니다.

---

소프트웨어의 본질: '문제 해결'과 '소통' 

취업 후 다양한 프로젝트를 경험하면서 책을 다시 펼쳤을 때의 느낌은 또 달랐습니다. 특히 4회독, 5회독째에는 단순히 "좋은 방식이란 무엇인가?"라는 질문을 넘어, "소프트웨어의 본질은 무엇인가?" 그리고 "우리는 왜 이 복잡한 소프트웨어를 만들고 있는가?"라는 더 근원적인 질문에 도달하게 됩니다.

이 책의 부제처럼 "소프트웨어의 복잡성을 다루는 지혜"는 기술적인 난이도에만 국한되지 않습니다. 오히려 가장 큰 복잡성은 업무를 둘러싼 이해당사자(stakeholder) 간의 의사소통과 활동에서 비롯됩니다. 비즈니스 요구사항을 개발자가 오해하거나, 개발자의 기술적 한계를 비즈니스 담당자가 이해하지 못하는 순간, 우리는 산으로 가는 프로젝트의 길목에 서게 됩니다.

이 책은 "모델의 깊은 통찰력은 진정한 전문가와 끊임없이 소통하고, 그들의 마음속에 있는 개념을 이해하려고 노력하는 데서 온다"고 말합니다. 실제로 제가 참여했던 한 프로젝트에서 특정 도메인 용어가 부서마다 다르게 해석되어 큰 혼란이 발생한 적이 있습니다. 예를 들어, '데이터'라는 단어가 한 모듈 안에서는 '사용자 정보'를 의미했지만, 다른 모듈에서는 '통계 자료'를 의미하는 식이었죠.

이때 DDD의 유비쿼터스 언어와 통합된 컨텍스트(Bounded Context) 개념을 적용하여 각 컨텍스트 별로 용어를 정리하면서 이야기를 하며 소통의 질을 올릴수 있었습니다.

결국 소프트웨어는 업무에 대한 문제를 해결하는 도구이며, 이를 위해서는 도메인 중심적으로 접근하여 모든 이해관계자가 동일한 언어로 소통하고 협력하는 것이 필수적임을 깨달았습니다.

---

DDD는 살아있는 '모델', 끊임없이 진화한다 

또 이 책은 말합니다. "소프트웨어 개발에서 가장 중요한 것은 핵심 도메인을 명확히 식별하고, 그곳에 우리의 모든 지적 노력을 집중하는 것이다."라고 이것은 제가 실무에서 가장 크게 와닿았던 부분입니다. 실제 프로젝트에서는 항상 자원이 제한적입니다. 모든 요구사항을 완벽하게 구현하는 것은 불가능에 가깝죠. 이때 핵심 도메인(Core Domain)을 식별하고 여기에 집중함으로써 비즈니스 가치를 극대화하고, 나머지 지원 하위 도메인이나 일반 하위 도메인에는 적절한 전략(외부 솔루션 활용, 간소화 등)을 적용하는 것이 현명한 선택임을 깨달았습니다.

또한, DDD는 한 번에 완성되는 정적인 설계가 아니라, 큰 그림으로 시작하여 반복적이고 지속적인 리팩토링과 이해당사자들과의 협력을 통해 모델을 발전시켜야 한다는 점이 중요합니다. 실제 업무에서 새로운 요구사항이 추가되고, 기존의 가정이 틀렸음이 밝혀지는 상황은 비일비재합니다. 이때 모델을 유연하게 수정하고 발전시킬 수 있는 능력이야말로 DDD가 제공하는 진정한 가치입니다. DDD는 우리에게 "틀릴 수 있다. 하지만 배움을 통해 계속 나아가라"고 말해주는 듯합니다.

에릭 에반스의 책은 단순히 기술적인 방법론을 넘어, 소프트웨어 개발의 본질, 즉 '사람'과 '소통', 그리고 '변화'를 다루는 인문학적인 통찰까지 제공합니다.

 

 

5회독을 마치고 보니, 이 책은 제가 개발자로서 성장하는 과정에서 길을 잃지 않도록 든든하게 지탱해주는 나침반과도 같다는 생각이 듭니다.