도메인 주도 설계(Domain Driven Development)

 

 

'DDD'

 

 

 

뜬금없는 이 영단어는 무엇을 의미하는 것일까? 닌텐도 게임 중 별의 커비에 나타나는 디디디 대왕? 아니면 유희왕 카드에 나오는 카드군?

 

이 단어를 보고 생각하는 단어들은 무수히 많겠지만 오늘은 Domain Driven Development 즉 도메인 주도 설계 라는것이 무엇인지에 대해 알아보는 시간을 가져보도록 하겠다.

 

먼저 아래의 그림은 일반적인 프로세스를 운영할 때 필요한 직종과 그 프로세스에 대한 표 이다.

 

기존 운영팀과 프로세스

서비스를 만들거나 매출을 내는 직군은 크게 기획자, 마케터, 개발자, 디자이너 로 4가지 직군이 있다.

기획자는 사업과 서비스를 기획하고 이 기획에 대한 상세한 요구사항을 정의해 둔다. 마케터의 경우 기획자와 비슷하게 사업계획을 수립하고 지표 관리를 한다. 직접 서비스를 개발한 후에 마케팅을 진행하며 마케팅 지표를 관리하며 이것을 통해 추가적인 아이디어를 제안할 수 도 있다. 개발자의 경우 구상해 놓은 것을 설계(어떤 DB를 할 것이며 개발의 구조는 어떻게 할 것인지? 등)하며 구현(제작), 그리고 유지 및 보수(수정, 재배포 등은 어떻게 할 것인가 등등)를 하는 것을 주요 업무로 삼고 있다. 

 

이런 사이클에서 각각의 관점은 너무나도 다를 수 밖에 없다. 트러블들을 관리하고 조율하기 위한 직종을 PM이라고 이야기하는데 PM이 어떻게 하느냐에 따라 120%이상의 효율이 나타날 수 도 있고 80%이하의 효율이 나타날 수 도 있다. 주로 일정관리와 조율, 그리고 각 분야의 이야기(요구 및 조율. ex) 기획자가 이것저것 다양하게 기획을 했지만 현실적으로 개발하기 힘들때 이것을 어떻게 조율할 것인가. 기획이 부실하게 되어서 디자이너가 기획의 업무를 해야하는 경우 어떻게 해야하는가 등)를 들어주는 역활을 한다.

 

만들어진 팀을 기반으로 먼저 어떤 서비스를 만들 것 인지에 대한 시장조사를 하게된다. 여기서 획득한 자료를 바탕으로 하여 구체적인 서비스 기획을 하고 베타 서비스를 개발하게 된다. 베타를 기반으로 소규모 마케팅을 실행한다. 마케팅을 실시하게 되면 다양한 피드벡이 오게되고 이 정보를 바탕으로 수정 기획을한다. 여기서 획득한 자료를 바탕으로 하여 다시 시장에 마케팅을 선보인다. 여기서 획득된 자료를 바탕으로 반복적으로 수정, 기획, 서비스 개발, 마케팅이 서비스가 종료되는 시점까지 순환이 된다.

 

이런 기존의 프로세스는 큰 문제가 생기는데 그 문제는 다음의 밈으로 한 번 에 설명할 수 있다.

이 상황을 한 마디로 설명하면 '개판 5분전'이라고 설명하기 딱 좋을 상황이다. 고객은 단순한 개념을 요구하고 그것을 설명했지만 PM, 개발자, 아키텍처 등등 모두가 이해하고 받은 자료는 다르다. 

 

1. 서비스가 복잡하다.

 ==> 굉장히 쉬워 보이는 서비스도 직접 개발하게 된다면 구현해야하고 관리해야하는 부분이 굉장히 많다.

 

2. 관점이 다르기 때문에 소통하기 어렵다. 기획자와 개발자의 대화를 상상해 보자.

 

 기 : 로그인기능을 추가해 주시고 여기 버튼을 클릭하면 A라는 기능이 되도록 만들어 주세요.

 개 : 음.. 그렇게 할려면 먼저 C+와 Python을 통해서 이것을 개발해야해요!

 기 : ?? C+? 왜 학점을 이야기하시지..? 파이썬..? 스타크레프트 좋아하시나..? 개임하자는 소리이신가..?

 

와 같은 극단적...인 상황이 발생할 수 도 있다. 이런 상황을 조금 정리해서 설명하자면 소프트웨어 개발과 도메인과 모델사이의 불일치가 발생하게 된다. 즉 도메인이 복잡해서 서로가 이해하기 힘들어 진다. 라는 의미가 된다.

 

도메인이라는 것은 쉽게 말해서 그 분야의 지식을 알고 있다. 와 같은 개념이다. A는 교육시장에서 도메인 지식을 알고 있습니다. 라고 한다면 A라는 사람은 교육시장에 대해 기본적으로 깊고 넒은 지식을 알고 있다 라는 의미이다. 이런 지식을 필요없는 부분과 필요한 부분으로 나누어서 구분하고 추상화 시킨 이 후 어떤 서비스를 만들 것인지 모델화(설계도) 해야한다. 이런 모델을 개발자들은 실제로 구현하고 그 결과물로서 SW가 탄생하게 된다.

 

이런 문제를 해결하기 위한 고민을 시작으로 DDD가 나타나게 되었다. DDD를 한마디로 요약하자면 '상호간 소통을 좀 더 원할하게 하자.' 라는 개념이다. 소프트웨어가 복잡한 원인은 도메인때문이며 이를 극복하기 위해 '보편언어를 사용해야하며 모델 주도 설계를 해야하는것이 중요하다.' 라고 이야기한다. 즉 DDD는 하나의 기술, 개발이 아닌 방법론이다.

 

보편언어

모든 사람이 이해할 수 있는 공통된 단어, 어휘를 사용하는것이 필요하다. 쉽게 말해서 토론, 토의를 할 때 단어의 정의를 먼저 내린 이 후 토론하는것과 같은 개념이다. 

 

모델 주도 설계 

도메인 분석과 설계의 간극을 최소화 하자. 그리하여 분석/설계/구현 등의 모든 단계를 하나의 모델로서 만들어서 유지하자. 즉 기획자가 만드는 모델과 개발자가 만드는 코드는 같은 내용이 되어야한다. 임원진, 개발자, 마케터 등 모든 사람들이 같은 모델을 보며 대화를 하자. 라는 개념이다.

 

이런 DDD는 전략적, 전술적인 설계로 나뉘어 지는데 전략적 전술은 이름에서 부터 알 수 있듯이 광범위(broad)하다. 구체적으로 어떤 방향으로 나아가는것이 좋을까 를 고민한다. 전술적 설계는 전략적 방향에서 나아갈 방향을 정한 후 이 방향에서 세세하게 어떤 것을 할 것인지를 정하는 개념이다. 

 

전략적 설계

비즈니스의 상황에 맞게 설계해야한다.

모든 상황에 대한 이벤트 스토밍(브레인 스토밍과 비슷하다.)을 통해서 공유해야한다.

 ==> 이 서비스에서 일어날 수 있는 모든 상황에 대해 고민해 보자.

공유된 것을 바탕으로 모든 상황을 그룹화 시키자

 ==> 많은 상황을 비슷한 유형으로 구분하여 모델화, 추상화를 시키기 위함이다.

이것을 바탕으로 Bounded context간의 관계를 정의하자.

 ==> 서로 어떤 관계이닞 간단히 정리해 눈에 보기 편하도록 만들자.

==> 이런 과정을 거치고 나면 하나의 도메인 모델(서비스의 추상화한 설계도를 분리-연결을 한다.)을 만들게 된 것이다.

 

전술적 설계

더 상세한 부분(Bounded context의 내부)을 모델링한다.

모델 주도로 설계를 한다. 가장 유명한 설계 방법으로는 Aggregate pattem 이 있다.

계층형 아키텍처를 통해 도메인 모델을 분리하고 도메인 이벤트를 통해 보다 명확하게 모델링한다.