인프런 커뮤니티 질문&답변

안녕하세요. 아주 날카로운 질문을 해주셨네요.

클린 스프링 예제를 만드는 중에 DDD를 하는 건 아닙니다라고 얘기한 건 DDD의 정의인 복잡함을 다루는 도메인은 "아직은" 아니다라는 걸 강조하기 위해서 드린 말씀입니다.
DDD에 관한 전문가들의 이야기를 하나 공유해드릴게요.

DDD는 끊임없는 지식 탐구 활동을 통해 적절한 도메인 모델을 선택하고, 선택된 도메인 모델을 기반으로 분석, 설계, 구현에 걸친 소프트웨어 개발 전 과정을 주도하고, 모델을 의사소통의 핵심 수단으로 사용하기 위해 적용할 수 있는 기법과 패턴의 집합이다.
도메인 주도 설계는 매우 복잡하고 잘 정의된 비즈니스 모델에 초점을 맞추어야 하는 소프트웨어를 개발할 때 적용하기 적절한 방법이다. 아마 모든 소프트웨어 애플리케이션의 95%는 "도메인 주도 설계를 적용하기에 적절하지 않은 범주에 속할 것이다. 대부분의 소프트웨어는 근본적으로 데이터 중심적이다 대부분의 웹 사이트가 그렇고, 대부분의 데스크톱 애플리케이션이 그렇다. 사실 데이터를 수정하고 보고하는 대부분의 애플리케이션은 데이터 중심적이라고 할 수 있다. 나머지 부류의 애플리케이션이라고 하더라도 매우 복잡한 도메인을 가진 경우는 많지 않다. 대부분은 단순하거나, 소프트웨어의 규모가 크더라도 그렇게 복잡하지는 않다. 도메인 주도 설계를 적용하기에 적절한 나머지 5%의 애플리케이션의 경우 도메인 주도 설계를 적용하기에 매우 적합하다고 할 수 있다. 이 경우에 도메인 주도 설계를 적용하면 어렵고 복잡한 문제를 해결하는데 매우 큰 도움을 얻을 것이다. 이런 상황이라면 도메인 주도 설계는 늑대를 물리치기 위한 은 총알이 될 지도 모른다. 비록 애플리케이션이 도메인 주도 설계에 적합한 5% 범주에 포함되지 않는다고 하더라도 도메인 주도 설계에는 많은 지혜와 경험이 녹아 있다. 자신의 상황에 적용할 수 있다고 생각되는 기법을 적용하면 소프트웨어가 좀 더 유연해지고, 사용자에게 더 잘 반응하며, 이해하기 더 쉬워진다는 사실을 알게 될 것이다.

DDD를 적용하기 적절하다는 5%라는 게 어떤 연구를 통해서 밝혀진 수치는 아니지만 경험에 의해 대략 그 정도 비율이 되지 않겠느냐는 의견이고 저도 동의합니다. 도메인 규칙이 복잡하고 계속 변경되고 진화하며 상호연결점이 많아서 이해하기도 복잡한 경우라고 느껴진다면 DDD에서 제안한 거의 모든 패턴과 도구, 그리고 도메인 모델을 연구하고 리팩터링하는 과정이 필요할 겁니다.

상당히 규모가 있는 기업의 전사적인 수준의 시스템을 개발하게 된다면 DDD의 전략 패턴이 매우 중요해집니다. 그때는 도메인 모델과 보편 언어도 여러개가 됩니다. 각 도메인 사이의 매핑 전략도 필요하죠. 그 중에서 집중할 핵심을 선정하고 정제하는 작업, 큰 규모를 효과적으로 다루기 위한 DDD의 전략들도 사용하게 됩니다. 이런 규모에 의한 복잡성도 있고요.

규모가 아주 크지 않아도 복잡한 세금 계산이라든가 불변식과 규칙이 많고 계속 변화하는 금융, 커머스 관련된 도메인도 복잡함을 잘 다루기 위해서 도메인 모델을 정교하게 만들고 발전시키는 작업이 필수입니다. 구성원들의 꾸준한 소통과 도메인을 깊이 이해하고 통찰을 얻어서 그걸 모델에 계속 반영하는 등의 작업이 필요한 경우가 있겠죠.

이런 도메인의 본질적인 복잡함과는 별개로 도메인과 설계, 구현이 따로 놀아서 점점 이해하기 힘들고 변경에 취약한 시스템이 주는 복잡함도 있습니다. 기술적인 코드와 도메인 로직이 혼재되어 있거나, 잘못된 설계로 중복이 많고, 로직이 이리저리 흩어져있는 경우도 있겠죠. 시스템 구현 중심, DB 중심으로 사고하고 개발하다 보면 도메인을 깊이 탐구하면서 발견해야 하는 좋은 인사이트를 놓치고, 도메인 전문가나 실무자들은 이해하기 힘든 구조가 되기도 합니다. 이런 경우에도 DDD가 도움이 될 수 있습니다. DDD를 만든 에릭 에반스의 책에 그런 예들이 여럿 등장합니다. 컨퍼런스에서 DDD가 무엇인가라는 제목으로 발표한 영상을 보셔도 그 힌트를 얻으실 수 있을 겁니다. https://www.youtube.com/watch?v=pMuiVlnGqjk

저도 아직 DDD를 통해서 복잡한 도메인의 문제를 풀어나가는 걸 계속 경험하려고 노력하고 있습니다. 그런 도메인에서 본격적으로 DDD를 적용해볼 수 있는 기회가 많아졌으면 좋겠습니다.

DDD를 하지 않는다고 하더라도, DDD에서 소개된 좋은 패턴과 전략, 실천법 들을 적용하는 것은 많은 유익이 있습니다. 클린 스프링에서는 일단 그 전략으로 접근하고 있죠.  

이 시리즈를 통해서 언젠가 보다 복잡하고 다양한 규칙을 적용해가면서 도메인 모델을 중심으로 이를 풀어가는 과정을 한번 담아보려고 구상중입니다.

안녕하세요, 인프런 AI 인턴입니다. 종운님께서 궁금해하신 내용에 대해 답변드리겠습니다.

도메인의 복잡성은 많은 요소에 의해 결정되며, 특히 DDD(Domain-Driven Design)에서는 이러한 복잡성을 다루기 위해 다양한 개념을 사용합니다. 일반적으로 도메인이 복잡해진 순간이란 아래와 같은 경우를 포함할 수 있습니다:

1. 비즈니스 로직의 과밀: 도메인에 많은 비즈니스 규칙이 포함되어 있고, 이 규칙들이 서로 얽혀 관리가 어려운 경우를 말합니다. 이러한 복잡성은 시간이 지남에 따라 추가되는 요구사항과 변경사항으로 인해 더욱 증가할 수 있습니다.

2. 도메인 간 상호작용의 복잡성: 각 도메인이 서로 상호작용하는 방식이 다양하고 복잡할 때, 특히 고객의 다양한 요구사항을 수용하기 위해서 도메인 간의 복잡한 상호작용이 요구되는 경우를 말합니다. 이는 결합도가 높은 경우 더욱 두드러질 수 있습니다.

3. 지식 탐색의 어려움: 도메인을 이해하기 위해 많은 지식이 필요하고, 이것이 문서화되지 않은 경우도 복잡성의 원인이 될 수 있습니다. 이를 해결하기 위해서는 코드보다는 모델을 통해 도메인을 설명할 수 있어야 합니다.

4. 유연성과 확장성의 부족: 변화하는 비즈니스 요구사항에 대해 유연하게 대응할 수 없는 도메인 구조는 복잡성을 증가시킬 수 있으며, 이러한 구조에서 쉽게 변경할 수 없는 부분들이 많아지는 경우를 의미합니다.

토비님의 강연에서 말하는 “복잡해진 순간”은 이러한 다양한 요소들이 결합하여 프로젝트의 관리와 유지보수가 어려워지는 시점이라고 할 수 있습니다. 이를 DDD로 접근함으로써 더 명확한 도메인 모델을 정의하고, 복잡성을 줄여나갈 수 있습니다.

이와 관련해 더 깊이 있는 논의가 필요하시다면, 다음의 이전 답변을 참고해 보시기 바랍니다:
- DDD와 복잡한 도메인에 대한 접근 방식

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.