도메인주도 개발(DDD) 가속화를 위한 도구와 방법을 살펴보자

잘 구성된 팀은 모델링할 때 필요하다면 무슨 도구든지 사용할 필요가 있지만 이것을 가지고 거대한 연회는 하지말자

DDD에서는 문서가 대화를 지배하는 상황을 경계해야할 대상으로 언급하고 있습니다.

DDD

모두가 동의할수 없으나, 애자일과 DDD가 추구하는 개발방법을 다음과같이 정리해보았습니다.

  • 애자일 : 예측 불가한 비즈니스때문에 ,프로젝트의 라이프 사이클을 짧게하여,지속 수정 가능한 유연한 개발방법 도입 ( 주로 폭포수모델의  한계점을 예를듬)
  • DDD : 오늘날 소프트웨어 복잡성은 기술보다 도메인의 복잡성및 변화에 기인하며 도메인을 중심에 두고 소통하고 발견하는 개발방법 도입 ( 주로 전문가와 단절이 된체 기술중심으로 문제를 해결하는 방식의 단점을 예를듬)


추구하는 방향은 약간 다를수 있으나,변화하고 복잡해지는 비즈니스 모델에 대응하기위해어떠한 방법론을 가질것인가? 고민하는 부분은 유사하며  목표 달성을 위해 사용하는 도구 또한 상당수 공유하고 있습니다.

애자일을 한다고 DDD를 못하는게 아니며, DDD를 한다고 워터폴을 하지말아야 하는것이 아닙니다. 



경계해야할것

경계해야할것 몇가지를 알아보고, DDD 도입을 위해 유용한 도구를 살펴보겠습니다.

작업셔플

작업 셔플 만을 이용하여  스토리를 잘정리하고,스프린트 단위로 잘 분류하여  프로젝트를 성공시킨다.

경계해야할것은 이것 자체가 우리 프로젝트는 잘 수행되고 있다라고 착각을 일으키는것이다.

화이트보드에 할일을 포스트잇으로 늘어놓고 완료되면 옮기기만 하는것, 이와 같은 방법은 스크럼을 올바르게 사용하는 방법이 아니다. 

작업셔플만 사용하게될경우 지식획득과 설계를 무시하게된며 , 해결과정은 관심없고 완료가 언제되느냐? 에만 집중하게된다.


UML/다이어그램

UML로 도메인 모델을 구체화하는 방법은 유용하다, 하지만 UML을 능숙하게 다룰수 있는 비즈니스 전문가는 없다.

또한 수많은 회의를 통해 도메인 모델이 구체화되어도 그것은 개발자만(그중에서도 UML에 익숙한) 정리가능하고 문서화 할수있는부분으로

숙력도와 상관없이 실패해왔다. 그것을 정리할 시간은 애시당초 주어지지 않으며 지속적인 업데이트는 어렵기때문에

어느순간 UML은 우리의 도메인 모델과 멀어져 있으며, 최근에 작성된 기능임에도 불구하고 작동방법을 확인하는 방법은

코드는 분석이 안되고 실행해보는것 밖에 존재하지않는다.

비즈니스 전문가를 프로젝트 초기에 참여시킬수 있는 방법이 필요하며 화이트 보드와 포스트잇이면 충분하다.

프로젝트 초기 핵심 도메인 발견에 혼자만의 심오한 생각이 깃든 기획문서, 화려한 목업 UI, 거창한 UML등   과감하게 버리자

핵심 도메인을 발견하고 가속화하는데 걸림돌이 될뿐이다.

모델링은 전문적일 필요가 없으며 그것을 전달하고자 하는 아이디어이면 충분하다.



도전과제

도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고?

우리는 무엇을 같이 알고 있으며 , 앞으로 무엇을 알아내야만 하는가? 

숨겨진 도메인의 정수를 찾아내고 발견하기 위한 효율적인 방법과 툴을 찾고 이용하는것입니다.


Story Mapping

우리가 해야할것이 무엇인가? 사용자의 입장에서 정리를 하는것이다.

애자일에서 등장한 방법이며 DDD와 중복되는 사항만 간략하게 요약해보자

사용자의 입장에서, 사용자가 이해하는 쉬운 용어를 사용해야한다. 

그래야 사용자 관점에서의 좋은 소프트웨어를 만들수 있다.


내부에서 사용하는 용어조차 통일된적이 없는상태라고 하면  각각의 다른분야의 전문가들이 모여

사용자의 입장에서 사용하는 용어를 만드는것이 쉬울까?

더 큰 문제는 내부에서 사용할 잘못된 용어조차 존재하지 않았다란 사실이다.


DDD에서는 내부에서 사용할 보편언어를 통일하고, 그 언어기반으로 도메인 모델을 발견하는데 가속화해야하는것을 강조하고있으며

새로운 도메인모델(용어)를 찾는 활동도 포함되어 있습니다. DDD의 모든 활동 심지어 그것이 코드레벨까지 가야함을 강조합니다.

사용자는 당신을 위한 제품을 원하지 않는다.

스토리 맵핑에서 이상적인 문구는 다음과 같아야 하지만

  • 사용자로서 이러한 기능이 있으면 편리 할것같다.

숨겨진 본질은 다음과 같습니다.

  • OO 로서 이러한 기능이 프론트에 노출되면 좋겠다.


이것은 사용자의 입장에서 생각하라는 이야기가 아닙니다.

사용자 편의성에대해 사용자와 이야기를 한번도 한적없을 뿐더러 수집해본적이 없다란 사실에대해 이야기를 하고있습니다.

역설적으로 필요한 기능에대해 사용자와의 피드백이없으면, 그것은 사용자를 위한 기능이 아니라 당신을 위한 기능이다란 것입니다.


DDD에서는 구체적으로 다음과 같은 이야기를 합니다.

도메인에 대한 깊은 지식 없이 복잡한 은행 소프트웨어를 만드는것이 가능할까?

누가 은행업무를 아는가? 소프트웨어 아키텍트? 아니다. 그는 단지 자기 돈을 안전하게 보관하다가 필요할 때 인출하려고 은행을 이용할뿐이다.

소프트웨어 분석가? 역시 아니다. 그는 모든 자료가 주어졌을 때 해당 주제에 대해 분석할 줄 알 뿐이다.

개발자? 잊어버리자

그럼 누구일까 바로 은행가이다. 은행업무 체계는 거기에 속해 있는 해당 분야의 전문가들이 가장 잘 이해하고 있다.

우리가 출발해야하는 곳은 언제나 도메인이다.

  • 도메인 주도 설계란 무엇인가? 16페이지


참고 링크

이벤트 스토밍

참여자는 모두 클래스나 데이터베이스가 아닌 이벤트와 비즈니스 프로세스에만 집중하여

핵심 도메인 이벤트를 과거순으로 나열한다.

자신이 개발자라고 하면, 잠시 개발자임을 잊자~ 개발자만 알고 있는 전문 용어는 이 세션에 아무런 도움이 되지 않을뿐더러

핵심 도메인 이벤트를 찾는데 방해가 된다. 이과 정에서 개발 전문 용어가 단한번이라도 나오면 비즈니스 전문가의 도움을 받는것을 포기하라

이벤트를 나열하는 단계에서,제약 사항을 예측하면서 초반에 이야기를 끊는것 또한 경계해야한다. 끝까지 경청하고 불필요하면 나중에 제거하면된다.

첫단계에서 중요한것은 중복이 있더라도 빠짐없이 도메인 핵심 이벤트를 나열하는것이다.

이것은 아이디어 단계가 아닌, 숨겨진것을 정수를 찾는 활동임에 유의하자


중복을 제거하고, 중요한 이벤트의 순서를 찾아내는것은  아래에 설명된 추가 규칙을 참고하여 진행하면된다.

사용되는 포스트잇 색상

수행자,책임자 : 외국 원서는 사물체를 사람으로 표현하는 경향이 있어 조정합니다. 도메인 이벤트에 관련된 중요한 요소(아이템) 도 포함됩니다.

가입에 관련된것이면 고객일수있고 장바구니에 관련된것이면 상품아이템일수 있으며 승인에 관련된것이면 관리자가 될수도 있습니다.

작성순서

이벤트 작성

  • 비즈니스 프로세스에 촛점을두고 도메인 이벤트를 최대한 만들어라 
  • 이벤트는 과거완료형이여야하며 , 큰 그림에대한 스토밍진행중이라고 하면 너무 자세한 이름이라고하면 다른 이름을 사용해야한다.
  • 이벤트가 발생하는 과거순으로 준비된 이벤트를 붙인다.(동시일경우 하부에 위치할수도 있다.)

명령정의

  • 이벤트가 정해졌다고하면, 이벤트를 발생시키는 명령을 정의
  • 가끔 어떠한 명령은 다른시스템에의해 생성된 이벤트일수도 있다.
  • 명령이 수행될때 특정 역활이 중요하다고 하면 노란색으로 상위에 붙이다.
  • 명령을 생성하다보면, 생각하지 못한 이벤트를 발견할수 있다. 즉각 표현하자

완성된 이벤트 스토밍의 형태

Example Mapping

스토리 맵의 연장선으로, 스토리가 주로 사용자 입장에서 필요한것들을 정리하였다고 하면

여기서는 그것을 구현하기위해 구체적으로 무엇이 어떻게 작동하는가? QA입장에 더 가깝다.

BDD에 베이스를 둔 내용이며 다음 BDD자료를 참고바란다. 

참고 : BDD (Behaviour-Driven Development)


시나리오에 기반을 둔 테스트 케이스가 작성되며, 구현해야할 내용역시 도출가능한것이 최종 목표이다.

표준버전과 약간 다를수 있으며 표준버전은 더 많은 이야기를 하고있다.

여기서는  필자가 실제 이방법을 사용해 진행했던경험을 바탕으로  간소버전으로 정리해보겠다.

스토리 맵핑에서 스토리를 적당하게 나열하기

스토리를 너무 많이 나열하면, 해당 미팅시간에 완료를 다 할수 없으며  관련내용을 적당한수의 스토리만큼 나눠야하며

미팅참가전에 논의해야할 스토리 범위를 알고 있고 적당히 생각하고 있어야합니다.

이것을 나누는 팁은. 아래에 언급될 케이크 먹기좋게 잘라먹기 링크를 참조


사용자로서 구매성공

하면  알림을 받는다.

적절한 케이스가 아닐수도 있지만,이것은 사용자 스토리이다.  하지만 이것만 가지고 개발을 진행하기에는 부족해보인다.

사용자 스토리는 개발용어를 포함하여 개발적인 구체적인 내용을 언급하지 않는게 원칙이기 때문이다.

스토리 기준으로 개발팀이 구체적으로 무엇을 구현 해야하는지  지침서 같은게 필요하며

스토리에 룰과 예제를 추가적으로 연결하여 안개속에 가려져있는 구현해야할 사항에대해 정리하는 시간이된다.

참여자는 BA,QA,개발자 그리고 스크럼 마스터가 진행을 할수있다.

규칙 만들기

푸시시스템은 

알림 이벤트 수신시

알림을 보내야한다.

유져 스토리에 관련된 규칙(Rule)을 여러개 만든다. 이 Rule이 Task단위,개발자에게 할당 될수있음을 고려하자

규칙은 기획(BA),개발,QA등 이 미팅에 참여한 모두가 규칙을 만들어낼수 있다. 

이 규칙에서 중요한것은, 그것을 작동 시키는 주체(ex>푸시시스템)를 할수있다면 명확하게 지정하는게 좋다.

만약에 없다고하면 우리는 그러한 시스템을 아직 가지기전 일것이다.

예를들기

사용자가 구매를하면

1초이내에

실시간 알림을 받는다.

그리고 미팅참여자는 룰에 기반하여 위와 같이 예를 최대한 많이 만들어낸다.

최대한 많이 만들어내어야한며 , 바보같은 예라도 상관없다.

오히려 바보같은 예시가 도움이 되는경우도 있다. 영어식 표현으로는 given/when/then 이며. 

한국식은 예를 들면이다. 


위 와같은 예에 질문 응답시간이 필요하며, 이때 개발자는 현실적으로 작동가능한가? 고민을 해야한다.

여기서 결정난것은 실제 구현으로 이어지기 때문이다.


위 예를 개선하는 방법은 다음과 같다.

실시간이란 물리적 제약을 극복하기 어렵고 5초이내이면 충분하기 때문에 푸시시스템의 최소 전송보장시간은 5초로 조정되고

그에 따른 예 역시 5초로 조정될수 있다.

프로덕트 책임자도 이 회의에 참석을 하였으며, 대부분 어떠한 중요한 규칙의 옵션값을 정하거나 필요없는 기능에 대해 없애는 의사결정을 수행하였다.

Task는 어떻게 나누는가?

Example Mapping 이후 Task 단위를 다시 측정하여 할당하는데 또 추가적인 회의가 필요했다.

이 불필요한 시간을 줄여보려고 Rule과 Task 단위를 최대한 맞추려고 노력을 하였으며

이것을 맞추는데 시행착오를 거쳤다.  어떠한 Rule은 프론트와 백앤드가 같이하는 해야만 하는것

심지어 어떠한 Rule은 원격에 존재하는 개발팀의 도움을 받아야했기때문이다.


Rule을 어떠한 방식으로 다시 나뉠것인가? 그룹핑? SubTask? 

이러한 맵핑을 사용하는 팀은 이미 애자일문화가 정착이 되어 있고, 유져 스토리를 활용중에 있으며

유져스토리를 다른 방식으로 분류하고 칸반 보드와 일치를 이미 한 상태였기때문에

새로운 Task 분류법이 칸반 보드와 호환이 되지 않는 문제가 발생하기도 하였고 칸반보드를 수정하였다.

Task를 유연하게 만들것인가? 데시보드를 깨트리는 Task 생성을 금지할것인가?  어려운주제이다.


스토리를 어떠한 Task단위로 자를것인가? 란 주제자체가 사실은 아주 어려운 부분이며

Rule은 스토리 베이스로 한번더 나뉜 형태이기는 하나, 일하기 좋은 단위로 나뉜것은 아니며

불일치 하는 경우가 발생할수 있습니다. 

스토리를 일하기 좋게 Task단위로 분류할것인가? 다음 자료를 참고합니다.

참고자료 : https://blogs.adobe.com/agile/2013/09/27/splitting-stories-into-small-vertical-slices/


연관된 DDD 이야기를 하자고하면, 바운디드 컨텍스트를 나누고 결정하는것이 가장 어려웠다.

단순하게 4x4 로 쪼갤수 있는부분이아니고 기술문제를 포함 책임영역까지 고려해야하기때문이다.

큰단위를 작은단위로 나누는것은 사실 세심하고 어려운 공정이다.


SWOT 분석사용

DDD를 포함 우리의 개발 프로세스가 잘 수행되는지 어떻게 알수 있는가? 스프린트가 존재하면 스프린트단위로 수행하고, 없다고 하면

DDD,애자일과 별개로 운영할수도 있다.


강점과 기회는 긍정적인것이라 어떠한 타이밍에 누구든 이야기해도 상관없다.

여기서 중요한것은 모두가 동등한 입장에서 약점과 위협을  이야기 할수 있어야 한다는것인데

대부분의  조직문화 특성상 이러한것을 아무장소 아무상황에 말하기는 쉽지않을것이다. 

이것을 자연스럽게 지속적으로 이야기하는 문화가 더 중요하며, SWOT는 그것을 이야기할수 있는 방법중 하나일뿐이다. 

마무리

여기서 소개된 도구가 언제 사용이 되는가? 에 요약이며  언제 얼만큼 사용해야 효과가 있는가? 는 선택과 팀이 학습해야할 과제입니다.

  • Story Mapping/Impact Mapping : 중요 프로덕트 요구사항 나열 할때  -주로 기획주도 사용자로부터 요구사항접수
  • 이벤트 스토밍 : 프로덕트 요구사항을 분석할떄 
  • Example Mapping : 실제 어떻게 작동되어야하는지 더 구체화(개발용어가 이때부터 등장가능하며,케익을 어떻게 짜를까에대한 고민도 병행됨,아래 링크참고)
  • SWOT : 스프린트가 끝날때마다 , 모든것을 점검(회고)하고 다음 스프린트 우선순위 조정에 영향을 줌


도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다. 

커피한잔으로 가능한 일이면, 위 툴은 필요없어도 됩니다.

DDD에서 커피가 가장 강력한 툴인것을 깨닫는 것입니다.


참고자료




  • No labels
Write a comment…