도메인주도 개발(DDD) 가속화를 위한 도구와 방법을 살펴보자 잘 구성된 팀은 모델링할 때 필요하다면 무슨 도구든지 사용할 필요가 있지만 이것을 가지고 거대한 연회는 하지말자 DDD에서는 문서가 대화를 지배하는 상황을 경계해야할 대상으로 언급하고 있습니다. |
모두가 동의할수 없으나, 간단하게 애자일과 DDD를 한문장으로 정의해보자
이야기하는 패러다임은 완전하게 다르나,변화하고 복잡해지는 비지니스 모델에 대응하기위해어떠한 개발 문화를 가져야할까? 고민하는 부분은 동일하며 목표 달성을 위해 사용하는 도구 또한 애자일에서 출범하긴하였지만 상당수 공유하고 있습니다.
경계해야할것 몇가지를 알아보고, DDD 도입을 위해 유용한 도구를 살펴보겠습니다.
작업 셔플 만을 이용하여 스토리를 잘정리하고,스프린트 단위로 잘 분류하여 프로젝트를 성공시킨다.
경계해야할것은 이것 자체가 우리 프로젝트는 잘 수행되고 있다라고 착각을 일으키는것이다.
화이트보드에 할일을 포스트잇으로 늘어놓고 완료되면 옮기기만 하는것, 이와 같은 방법은 스크럼을 올바르게 사용하는 방법이 아니다.
작업셔플만 사용하게될경우 지식획득과 설계를 무시하게된며 , 해결과정은 관심없고 완료가 언제되느냐? 에만 집중하게된다.
UML로 도메인 모델을 구체화하는 방법은 유용하다, 하지만 UML을 능숙하게 다룰수 있는 비지니스 전문가는 없다.
또한 수많은 회의를 통해 도메인 모델이 구체화되어도 그것은 개발자만(그중에서도 UML에 익숙한) 정리가능하고 문서화 할수있는부분으로
숙력도와 상관없이 실패해왔다. 그것을 정리할 시간은 애시당초 주어지지 않으며 지속적인 업데이트는 어렵기때문에
어느순간 UML은 우리의 도메인 모델과 멀어져 있으며, 최근에 작성된 기능임에도 불구하고 작동방법을 확인하는 방법은
코드는 분석이 안되고 실행해보는것 밖에 존재하지않는다.
비지니스 전문가를 프로젝트 초기에 참여시킬수 있는 방법이 필요하며 화이트 보드와 포스트잇이면 충분하다.
프로젝트 초기 핵심 도메인 발견에 혼자만의 심오한 생각이 깃든 기획문서, 화려한 목업 UI, 거창한 UML등 과감하게 버리자
핵심 도메인을 발견하고 가속화하는데 걸림돌이 될뿐이다.
모델링은 전문적일 필요가 없으며 그것을 전달하고자 하는 아이디어이면 충분하다.
도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고? 우리는 무엇을 같이 알고 있으며,
앞으로 무엇을 알아내야만 하는가? 결국 이것을 알아내기위한 효율적인 방법과 툴을 찾는것입니다.
우리가 해야할것이 무엇인가? 사용자의 입장에서 정리를 하는것이다.
참여자는 모두 클래스나 데이터베이스가 아닌 이벤트와 비지니스 프로세스에만 집중한다.
자신이 개발자라고 하면, 잠시 개발자임을 잊자~ 개발자만 알고 있는 전문 용어는 아무런 도움이 되지 않을뿐더러
핵심 도메인 이벤트를 찾는데 방해가 된다. 이과 정에서 개발 전문 용어가 단한번이라도 나오면 비지니스 전문가의 도움을 받는것을 포기하라
이벤트를 나열하는 단계에서,제약 사항을 예측하면서 초반에 이야기를 끊는것 또한 경계해야한다. 끝까지 경청하고 불필요하면 나중에 제거하면된다.
첫단계에서 중요한것은 중복이 있더라도 빠짐없이 도메인 핵심 이벤트를 나열하는것이다.
중복을 제거하고, 중요한 이벤트의 순서를 찾아내는것은 아래에 설명된 추가 규칙을 참고하여 진행하면된다.
수행자,책임자 : 외국 원서는 사물체를 사람으로 표현하는 경향이 있어 조정합니다. 도메인 이벤트에 관련된 중요한 요소(아이템) 도 포함됩니다.
가입에 관련된것이면 고객일수있고 장바구니에 관련된것이면 상품아이템일수 있으며 승인에 관련된것이면 관리자가 될수도 있습니다.
아래링크 참고
영문 자료만 다수이고, 한글자료가 거의 없네요
DDD에서 중요한 요소중 하나이며, DDD 열풍은 없었나 봅니다.
DDD를 포함 우리의 개발 프로세스가 잘 수행되는지 어떻게 알수 있는가?
스프린트가 끝날때마다 점검을 하고, 다음 스프린트일때 우선순위항목을 결정하는데 사용할수 있다.
강점과 기회는 긍정적인것이라 어떠한 타이밍에 누구든 이야기해도 상관없다.
여기서 중요한것은 모두가 동등한 입장에서 약점과 위협을 이야기 할수 있어야 한다는것인데
어떤 조직문화 특성상 이러한것을 말하기가 쉽지않을것이다.
이것을 자연스럽게 이야기하는 문화가 더 중요하며, SWOT는 그것을 이야기할수 있는 방법중 하나일뿐이다.
여기서 소개된 도구가 언제 사용이 되는가? 에 요약이며 언제 얼만큼 사용해야 효과가 있는가? 는 선택과 팀이 학습해야할 과제입니다.
도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다.
커피한잔으로 가능한 일이면, 위 툴은 필요없어도 됩니다.
DDD에서 커피가 가장 강력한 툴인것을 깨닫는 것입니다.
참고자료