You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 32 Next »

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

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

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

DDD

모두가 동의할수 없으나, 간단하게 애자일과 DDD를 한문장으로 정의해보자

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


이야기하는 패러다임은 완전하게 다르나,변화하고 복잡해지는 비지니스 모델에 대응하기위해어떠한 개발 문화를 가져야할까? 고민하는 부분은 동일하며  목표 달성을 위해 사용하는 도구 또한 애자일에서 출범하긴하였지만 상당수 공유하고 있습니다.

경계해야할것

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

작업셔플

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

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

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

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


UML/다이어그램

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

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

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

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

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

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

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

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

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



도전과제

도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고? 우리는 무엇을 같이 알고 있으며,

앞으로 무엇을 알아내야만 하는가? 결국 이것을 알아내기위한 효율적인 방법과 툴을 찾는것입니다.


Story Mapping

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




이벤트 스토밍

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

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

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

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

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

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

사용되는 포스트잇 색상

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

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

작성순서

이벤트 작성

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

명령정의

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

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

Example Mapping

아래링크 참고

영문 자료만 다수이고, 한글자료가 거의 없네요

DDD에서 중요한 요소중 하나이며, DDD 열풍은 없었나 봅니다.

SWOT 분석사용

DDD를 포함 우리의 개발 프로세스가 잘 수행되는지 어떻게 알수 있는가?

스프린트가 끝날때마다 점검을 하고, 다음 스프린트일때 우선순위항목을 결정하는데 사용할수 있다.


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

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

어떤  조직문화 특성상 이러한것을 말하기가 쉽지않을것이다. 

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


마무리

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

  • Story Mapping/Impact Mapping : 중요 프로덕트 요구사항 나열 할때
  • 이벤트 스토밍 : 프로덕트 요구사항을 분석할떄
  • Example Mapping : 실제 어떻게 작동되어야하는지? 제약은 무엇인지? 테스트는 어떻게하는지 개발용어가 등장하기 시작하고 Task단위가 나오기 시작하는 단계 
  • SWOT : 스프린트가 끝날때마다 , 모든것을 점검(회고)하고 다음 스프린트에 영향을 줌


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

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

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


참고자료




  • No labels