도메인 주도 설계(Domain-Driven Design) in Real Project — 협업
DDD를 반영한 프로젝트에서는 협업이 매우 중요하게 여겨집니다. 소프트웨어와 프로젝트 구성원들의 역할과 협업을 필요로 하는 이유 등을 공유합니다.
TL;DR
- 도메인은 소프트웨어에서 사용자가 알 수 있는 곳에 있습니다.
- 도메인은 보편 언어(Ubiquitous language)를 통해 소프트웨어 전체를 관통합니다.
- 도메인 전문가는 자신의 도메인 지식을 어느 정도까지 소프트웨어에 반영할 수 있는지 쉽게 판단할 수 없습니다.
- 개발자의 사고방식은 소프트웨어의 구조와 코드에 그대로 드러납니다.
- DDD는 개발자가 도메인 전문가와 협업하도록 합니다.
- 자율성 vs 복잡성 vs 일관성을 위해 무엇을 고민해야 할까요?
소프트웨어와 사용자
소프트웨어의 UI와 기능은 사용자를 기준으로 만들어집니다. 여기서, UI란 사용자에게 표면적으로 보여지는 인터페이스인 소프트웨어의 화면이나 API 등을 말하고, 기능은 사용자에게 직/간접적으로 영향을 줄 수 있는 모든 동작들을 말합니다. 도메인(Domain)은 사용자와 사용자의 관점에 따라 변화합니다. 즉, 도메인은 소프트웨어에서 사용자가 알 수 있는 곳에 있습니다. 어디까지가 사용자에게 보여질 영역일까요?
사용자는 내부적으로 소프트웨어의 구성과 구현이 어떻게 되어 있는지 공개하지 않는 이상 알 수 없으며, 알 필요도 없습니다. 소프트웨어는 사용자가 사용할 때 의미를 지닙니다. 그러므로, 소프트웨어가 내부 동작 원리와 관계없이 사용자가 원하는 것을 볼 수 있고, 원하는 대로 동작한다면, 그 소프트웨어는 사용자에게 완벽하다고 할 수 있습니다.
소프트웨어의 범위는 어디까지 일까요? 기업에서 진행하는 실제 프로젝트에서, 소프트웨어의 범위는 단순히 하나의 프로그램이 아니라 그 소프트웨어를 도출해내기 위한 모든 환경을 포함할 수 있습니다. 관련된 모든 구성원들과 고객들은 물론이고, 요구사항의 수집 프로세스부터, 완성되어 최종적으로 외부에 공개되고 그것들 지속적으로 관리하는 것 등 소프트웨어는 이 모든 것을 아우릅니다. Conway’s law는 안타깝지만(?) 실제로 매우 잘 맞다고 생각합니다.
협업의 중심
그렇다면, 프로젝트에 관여하는 모든 구성원들은, 사용자들이 어떤 관점으로 소프트웨어를 바라보고 있는지 모두 알아야 할까요?
모든 것을 기억하고 있다면 좋겠지만, 사람의 기억력의 한계로 인해 모든 도메인을 이해하고 있는 것은 불가능합니다. 그래도 사용자의 변화에 대응하고 소프트웨어를 지속적으로 개선해야만 프로젝트가 성공하고 유지될 수 있습니다. 모든 프로젝트가 그렇듯이 DDD도 협업이 요구됩니다. 실제로, DDD의 방식이 반영된 프로젝트는 그렇지 않은 프로젝트보다 훨씬 더 긴밀한 협업을 필요로 합니다. 회의를 더 많이해야 하는 걸까요?
프로젝트를 진행하는 구성원들은 각자 자신의 전문 도메인 영역이 다릅니다. 예를 들어, 개발자는 개발과 관련된 기술적 지식을 가지고 있고, Product Manager는 제품과 직접적으로 관련된 지식을 가지고 있습니다. 인프라를 구성하시는 분들은 인프라 환경에 대한 지식을 가지고 있습니다. 각자가 순수하게 각자의 도메인 영역만을 생각하는 것이 아닌 협업을 통해 공유하고 조금씩 맞추어가는 과정을 거칩니다.
DDD가 반영된 소프트웨어는 수많은 도메인의 집합체입니다. 다시 한 번 도메인을 되짚어 보겠습니다. 도메인은 사용자가 사용하는 것입니다. 그리고 도메인들은 소프트웨어를 구성합니다. 이는 단순히 소프트웨어에 도메인을 넣는다는 것이 아닙니다.
도메인은 소프트웨어 전체를 관통합니다.
소프트웨어의 구조는 도메인과 도메인 간의 관계가 반영됩니다. 그리고 요구사항 수집, 우선순위 설정, 개발 환경 구성, 설계, 구현, 테스트, 배포까지의 프로젝트의 전 프로세스에 도메인들이 사용됩니다. 또한, 고객들을 포함하여 소프트웨어와 관련된 모든 사람들이 소통할 때에도 도메인이 언급됩니다. 이 때, 그 도메인들의 용어를 보편 언어(Ubiquitous language)라고 합니다. 보편 언어는 모든 사람들이 동일한 의미로 이해하고 있는 단어(word)입니다. 즉, 특정 도메인 ‘A’는 모든 사람이 ‘A’로써 이해하고 있어야 하며, 누군가 ‘A-1’로 이해하고 있다면 보편 언어로 사용될 수 없으며 이해를 맞추기 위해 추가적인 소통을 필요로 합니다. 정말 회의를 더 많이해야 하는 걸까요…?
보편 언어는 DDD에서 어느 무엇보다도 가장 중요한 요소입니다. 만약, 소프트웨어에서 사용되는 보편 언어가 모든 사람이 같은 의미로 이해하고 있다면, 이상적으로는 소통이 한순간에 끝나게되며, 각자 전문분야의 역할만 충실히 수행한다면 소프트웨어 프로젝트는 순조롭게 원하는 대로 만들어집니다. 반대로, 보편 언어의 이해가 맞지 않다면 소프트웨어 곳곳에 어긋남이 있을 것이고 여러 문제들과 이해를 맞추기 위해 회의가 계속 이루어질 것입니다.
즉, DDD를 반영함에 있어서 모든 소통과 프로세스는 도메인(보편 언어)을 일관되게 맞추고 이해하는 것을 중심으로 만들어집니다.
소프트웨어와 도메인 전문가
도메인 전문가는 해당 소프트웨어 프로젝트에서가장 많은 도메인 지식을 가지고 있는 사람을 의미합니다. 일반적으로 Product Manager, Business Anlayst, Product Designer 등의 직책을 가진 사람을 말합니다. 물론, 개발자 스스로가 기획까지 한다면 개발자 또한 도메인 전문가라고 할 수 있습니다. 이 분들은 소프트웨어 개발에 있어서 가장 많은 도메인 지식을 가지고 있습니다. 그리고 업무의 많은 부분이 도메인과 접하고 고민하는 일들입니다. 그렇다면 이 분들이 모든 도메인들을 이해하고 개발자 또는 다른 분들에게 그 이해를 전달만 하면 되는 것일까요?
안타깝지만 실무에서는 그렇게 쉽게 흘러가지 않습니다. 도메인 전문가는 자신의 도메인 지식을 어느 정도까지 소프트웨어에 반영할 수 있는지 쉽게 판단할 수 없습니다. 예를 들어, 어느 정도의 세부사항까지 소프트웨어에 구현될 수 있는지, 기술적 어려움은 없는지 등은 개발자에게 반드시 물어보아야 알 수 있습니다.
소프트웨어와 개발자
소프트웨어는 도메인의 집합체라고 하였습니다. 개발자는 단순히 기술 적용이 아니라, 도메인을 이해하고 소프트웨어를 개발해야 한다는 것을 의미합니다. 하지만 개발자는 도메인을 의식적으로 생각하지 않으면 DDD가 지향하는 소프트웨어의 목적을 벗어나기 쉽습니다. 개발자의 전문 분야는 기술적인 것에 치중되어 있으며, 실제로 소프트웨어 개발은 기술을 고민하고 적용하는 과정이며 도메인과 직접적인 연관은 없습니다. 따라서, 도메인에 대한 고민을 내려놓고 싶다면, 정말 쉽게 내려놓을 수도 있습니다.
소프트웨어에서, 겉으로 사용자에게 보여지는 것과, 소프트웨어가 동작하기 위해 사용하는 기술과 도구들은 그 목표와 동작 방식이 의미적/기술적으로 다릅니다. 예를 들어, 알파벳 ‘a’는 ASCII 코드로 ‘97’입니다. 사용자가 ‘a’를 필요로 하면, 개발자는 ‘97’을 넘겨주고 내부적으로 변환하여 겉으로 보이기만 ‘a’로 표현할 수도 있습니다. 이 때, 사용자는 도메인 ‘a’를 원하였고 결과적으로도 ‘a’를 받았지만, 개발자는 도메인 ‘a’를 전달한 것이 아닌 ‘97’이라는 ASCII 코드 데이터를 넘겨준 것에 불과합니다.
개발자는 개발을 위해 사용하는 도구 또는 프로그래밍 언어들의 특성과 사용 방식에 집중하며, 개발하는 동안 실제 소프트웨어의 의미를 점점 잊어갈 수 있습니다. 그리고 그 사고방식이 소프트웨어의 구조와 코드에 그대로 드러납니다. 결과만 정확하게 전달해주면 문제가 없을 것이라 생각할 수 있지만, 이는 나중에 소프트웨어의 목적을 잃어버리게 하는 근원 중 하나가 됩니다. 그리고 소프트웨어는 마치 알 수 없는 병에 걸린듯 서서히 무너져갑니다.
개발자의 자율성
지금까지의 내용을 보면, 사실상 개발자는 도메인에 종속되어 개발해야 합니다. 설계도 도메인을 중심으로 해야하고, 그렇게하면 기술도 마음대로 사용하기 힘들 것으로 느껴집니다. 정말 자율성이 줄어드는 것일까요?
DDD를 반영함에 있어서 개발자의 자율성은 바라보는 관점에 따라 더 넓어졌다고 느낄 수도, 더 좁아졌다고 느낄 수도 있습니다.
도메인 전문가는 요구사항을 도출하되, 최종적으로 여러 영역의 담당자들과 함께 합의된 부분들에 한해 소프트웨어 개발에 반영하게 됩니다. 먼저, DDD가 반영된 프로젝트에서 도메인 전문가와 개발자의 소통 과정을 살펴보겠습니다.
도메인 전문가가 담당한 영역의 표현과, 개발자가 담당한 표현이 서로 다를 경우 (같은 도메인에서 보편 언어를 사용하지 않고, 도메인 간의 관계를 서로 다르게 연결하고 있을 경우)
- 개발자는 도메인 전문가가 담당한 영역의 표현과 관계없이, 자신만의 표현으로 자유롭게 구조를 설계하고 개발할 수 있습니다.
- 도메인 전문가에 의해 요구사항이 변경되면, 개발자는 해당 요구사항이 의미하는 모든 표현(단어)들을 찾아서 변경해야 합니다. (단어 불일치로 인한 통역 과정)
- 개발자가 요구사항과 관련된 사항을 도메인 전문가에게 피드백하기 위해, 개발자 스스로 자신의 표현 방식을 도메인 전문가의 표현 방식으로 관련지어 전달해야 합니다.
도메인 전문가가 담당한 영역의 표현과, 개발자가 담당한 표현이 서로 같을 경우 (같은 도메인에서 보편 언어를 사용하고, 도메인 간의 관계를 서로 같게 연결하고 있을 경우)
- 개발자는 도메인 전문가가 담당한 영역의 표현과 동일한 구조로 설계하고 개발해야 합니다. (사용하는 도구가 다를 뿐입니다.)
- 개발자는 도메인 전문가의 표현을 그대로 구현에 반영하고, 그 표현의 하위 영역에서 설계와 개발의 자율성이 주어집니다. (순수하게 기술적인 영역)
- 개발자가 요구사항과 관련된 사항을 도메인 전문가에게 피드백하기 위해, 개발자는 도메인 전문가에게 사용한 표현 그대로 전달할 수 있습니다.
보편 언어를 일관되게 사용하는 프로젝트에서는 기술적인 관점에서 바라보면, 개발자는 도메인을 벗어나 무언가를 마음대로 할 수 없습니다. 구조를 기술적으로 마음대로 변경할 수 없고, 도메인을 벗어나서는 무언가를 구현할 수 없습니다. 그런데, 도메인의 관점에서 바라보면, DDD는 개발자의 자유를 제한하지 않습니다. 오히려, 생각할 수 있는 범위가 단순히 기술적인 영역에서 도메인까지 훨씬 더 넓어졌다고 할 수 있습니다. 개발자가 도메인을 이해하며 도메인 전문가와 함께 만들어 나아가는 것입니다. 단지, 자유롭게 움직일 수 있는 영역이 달라졌다고 할 수 있습니다. 이를 통해, 개발자가 도메인 전문가와 함께 협업하도록 합니다.
자율성 vs 복잡성 vs 일관성
일반적으로, 개발자가 도메인의 영역에서 벗어나 자유롭게 표현 할수록 소프트웨어의 복잡성이 증가합니다. 개발자는 자신이 개발하는 영역 내의 기술에 집중하여, 스스로 생각하는 시야를 줄이고 프로젝트에서 구조적 일관성이 없어지게 합니다. 이 때, 일관성이 없어진다는 것은 그만큼 복잡성이 증가한다는 것을 의미합니다. 자율성, 복잡성, 일관성은 서로 관계를 맺고 있습니다. 때로는 trade-off가 필요할 수도 있습니다. 무엇을 고민하고 어떻게 조절해야 할까요? 모든 것을 충족하며 만들어 나아갈 수 있을까요?
