도메인 주도 설계(Domain-Driven Design) in Real Project — 도메인
개발자로써 도메인 주도 설계(Domain-Driven Design, 이하 DDD)를 실무 프로젝트에 반영하면서 겪었던 경험들을 바탕으로, 고민하고 연구해왔던 내용들을 공유해보려고 합니다. 많은 분들이 DDD를 쉽게 이해할 수 있기를 바랍니다.
이 글은 Eric Evans가 출간한 ‘도메인 주도 설계-소프트웨어의 복잡성을 다루는 지혜’를 개념 설명을 위한 참고 자료로써 사용합니다. Eric Evans는 이 책을 출간하면서 DDD 개념을 정립하고 세상에 널리 알리기 시작하였습니다.
사실, 도메인(Domain)이라는 개념 자체는 새로운 것이 아닙니다. 개발의 기술적인 방법론과 접근 방법이 상충되고, 이에 따라 실무에 적용하기 위해 넘어야할 어려움이 있기 때문에 많은 개발자 분들이 주저하곤 합니다.
앞으로 작성할 내용들에서는 DDD의 근본적인 목적과 개념, 소통의 방식, 문제점과 보완 방법, 도메인의 설계와 구현 방법 등을 다룹니다. 내용이 꽤 많기 때문에, 여러 개의 글로 쪼개어 작성합니다.
TL;DR
- 사용자가 사용하는 것을 도메인(Domain)이라고 합니다.
- DDD는 소프트웨어를 이해하고 프로젝트를 성공적으로 완성하기 위한 사고방식이라고 할 수 있습니다.
- 도메인은 사용자에 따라 또는 사용자가 바라보는 관점에 따라 지속적으로 변화합니다.
- 도메인의 변경으로 발생되는 수많은 소프트웨어 변경에 어떻게 대응해야 할까요?
도메인 주도 설계(Domain-Driven Design)의 방향
DDD란 무엇일까요?
DDD의 목적… 소프트웨어의 복잡성을 최소화하는 것… 요구사항을 쉽게 반영할 수 있다. 소통이 원할하게 이루어질 수 있다. 개발의 범위를 쉽게 파악하고 스케줄링 할 수 있다. 설계를 일관되게 할 수 있다. 테스트가 쉽다 ………. 정말 모두 쉽게 가능할까요?
DDD를 개발 방법론(Development methodology)으로써 접근해보신적이 있으신가요? 어떤 고민을 하게 되셨나요? 어떤 문제들과 마주치셨나요?
“아키텍처를 이렇게 하면된다” “코딩을 저렇게 하면 된다”
이러한 것들을 따라하며 프로젝트에 적용하기 이전에, 기술적인 요들을 모두 잊어버리고 소프트웨어의 존재 가치를 진지하게 고민해볼 필요가 있습니다.
사용자가 사용하는 것들은 모두 도메인(Domain)이라고 합니다.
그렇다면, 사용자는 누구일까요? 요리와 관련된 소프트웨어라면 요리사? B2B라면 고객 기업? 오픈 API를 개발한다면 다른 개발자?
사용자가 사용하는 것이라는 매우 추상적인 접근을 통해, 자기 자신을 포함하여 그 소프트웨어와 관련된 모든 사람이 사용자라고 할 수 있습니다.
사용하는 것은 단 하나의 코드가 될 수도 있고, 하나의 버튼이 될 수도 있으며, 소프트웨어 전체가 될 수도 있습니다. 만약, 사용자가 어떤 단어 하나를 바라보고 있다면 그것은 중요한 도메인이 될 수 있습니다.
예를 들어, 요리사가 소프트웨어에서 요리 이미지를 볼 수 있다고 한다면, 그 요리 이미지는 하나의 도메인이고, 개발자가 조건문 하나를 가지고 고민하고 있다면 그 조건문도 하나의 도메인이 될 수 있습니다. 또는 기획자가 데이터를 소프트웨어에 효율적으로 반영하기 위해 둘러보고 있다면 그 데이터들도 도메인이 될 수 있습니다.
즉, 소프트웨어의 존재 가치는 사용자가 사용함으로써 의미를 가집니다.
다시 말하면, 소프트웨어는, 사용자가 이해하고 원하는대로 목적에 맞게 사용할 수 있도록 하는 것이 최고의 목표가 되어야 합니다.
DDD를 프로젝트에 반영하기 위해서는 기술보다 도메인이 더 높은 우선순위를 가져야하고, 어떤 문제를 하기 위해서는 항상 도메인을 먼저 고민하는 것을 필요로 합니다. 그리고 그 도메인들을 바탕으로 설계(Design)하고 프로젝트에 지속적으로/반복적으로 반영하여 개발(Developemnt)합니다.
여기서 다시 한 번, DDD란 무엇일까요?
소프트웨어를 이해하고 프로젝트를 성공적으로 완성하기 위한 사고방식이라고 할 수 있습니다.
OOP와의 차이
객체 지향 프로그래밍(Object-Oriented Programming)이 탄생한 배경과 개발 방법을 생각해보겠습니다. 객체(Object)라는 것은 현실의 개념들을 프로그램에 반영하여 절차 지향 프로그래밍(Procedural-Oriented Programming)의 문제들을 해결하기 매우 오래 전부터 개발 프로젝트에 사용되었습니다.
왜 아직까지도 순수한 OOP는 그 이상을 쉽게 실현하지 못하고 신뢰받지 못하는 걸까요?
저는 기술이 더 높은 우선순위가 되어 접근해왔기 때문이라고 생각하고 있습니다. 겉으로 보이는 프로그래밍의 객체 구조와 틀을 생각하며 라이브러리나 프레임워크와 같은 기술적인 요소와 알고리즘들을 통해 현실의 개념을 만드려는 노력이 오히려 이상을 실현할 수 없는 상황으로 만들었다고 생각합니다.
조금 더 들여다보면, DDD는 OOP의 이상향과 크게 차이가 없습니다.
도메인(Domain)과 객체(Object)의 차이는 무엇일까요?
큰 차이는 없습니다. 객체의 의미는 개발에서 실질적으로 기술에 더 가까운 의미로 사용되고 있지만, 탄생 배경으로 보면 객체도 충분히 현실 세계를 반영합니다. 실제 개발에서도 불가능하다고는 할 수 없습니다.
차이는 도메인과 객체가 설명하는 범위에서 나타납니다. 객체는 추상화 또는 구체화할 수 있는 특정 요소만을 표현하는 반면, 도메인은 사용자가 사용하는 모든 것을 설명할 수 있습니다.
예를 들면,
“고양이는 사과를 먹는다.”
객체의 관점에서는 “고양이”와 “사과”를 표현할 수 있고, “먹는다”는 객체가 하는 행위로 별도로 표현합니다. 도메인의 관점에서는 “고양이”, “사과”, “먹는다”, “고양이는 사과를 먹는다.” 모두 각각 도메인이라고 할 수 있습니다.
객체는 현실 그대로를 표현하고 있고, 도메인은 위의 문장을 읽는 사용자가 바라보는 관점에 따라 각각을 구분하거나 전체라고 할 수 있습니다.
여기서 하나의 질문을 던져볼 수 있습니다.
그렇다면, 도메인은 명확하게 정해져있지 않고, 사용자에 따라 또는 사용자가 바라보는 관점에 따라 계속 바뀔 수 있을까요?
네, 그렇습니다. 도메인은 사용자가 누구인가에 따라, 어떻게 사용하느냐에 따라 같은 요소라고 할지라도 계속 바뀔 수 있고, 형태가 고정되어 있지 않습니다.
어느 사용자가 “고양이”, “사과를 먹는다” 두 가지 관점으로 바라보고 있다면, 해당 문장에서의 도메인은 2개라고 할 수 있습니다.
소프트웨어 프로젝트에서의 고민
따라서, DDD의 사고방식을 반영한 실무 프로젝트에서의 도메인은 시간이 흐름과 동시에 지속적으로 변경됩니다. 위에서 서술한 것과 같이, 그 소프트웨어와 관련된 모든 사람들이 사용자(자신을 포함하여)이고, 사용자들이 지속적으로 변경됨과 동시에 그 사용자들이 바라보는 관점도 변화합니다.
소프트웨어 프로젝트에서 처음부터 완벽한 요구사항은 없고, 소프트웨어는 지속적으로 변화하며, 변화하지 않는 소프트웨어는 이미 죽은 소프트웨어입니다.
소프트웨어 산업에 종사하시는 분이라면, 위의 내용은 들어보셨거나 공감하는 내용일 것입니다. DDD가 반영된 소프트웨어는 수많은 도메인의 집합체입니다. 도메인의 변경은 곧 소프트웨어의 직접적인 변경으로 이어집니다. 사소한 것 하나에도 소프트웨어에 변경이 발생한다면, 얼마나 많은 시간과 노력을 들여야 할까요? 어떻게 소통해야 할까요? 어떻게 설계해야 할까요? 그리고 수많은 변경들을 어떻게 대응해야 할까요?
