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

Compare with Current View Page History

« Previous Version 7 Next »

DDD 가속화를 위한 도구와 방법을 살펴보자

잘 구성된 팀은 모델링할 때 필요하다면 무슨 도구든지 사용할 필요가 있다.

그것을 통해 커뮤니케이션에 활용할수 있습니다. 다만 비용이 너무 많아지는 파티나 연회는 하지말자

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

비지니스 모델의 핵심을 파악하는데 개발용어가 난무하는것 역시 우리의 지식탐구를 방해하는 요소가 될것입니다.

경계해야할것

작업셔플

 작업 셔플을 이용하여  스토리를 잘정리하고, 일정을 잘관리하여 완료로 가게하여 프로젝트를 성공시킨다.

경계해야할것은 이것 자체가 스크럼을 잘수행한이라고 생각하는것이다. 

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

스크럼은 지식획득과 설계가 진행되어야하는 것이 원칙이지만 위와같은 보드만 사용하면 지식획득과 설계를 무시하게된다.

해결과정은 관심없고 오로지 Done이 언제되느냐? 에만 집중하게되며 개발자의 노력만이 중요하게된다.


UML/다이어그램

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

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

숙력도와 상관없이 실패해왔다. 그것을 정리할 시간은 애시당초 주어지지 않으며 지속적인 업데이트는 거의 불가능하다.


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

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

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

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

도전 

DDD의 시작은 기획자/개발자 이분법이 존재하지 않는다. 비지니스전문가와 분석가 함께 존재할뿐이다.

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

기획문서의 완성도는 기획자의 고민으로 이루는 것이 아니며 애시당초 기획문서가 존재하지 않는다.

모두가 비지니스 분석가로서 미팅을 통해 비지니스에대한 이해의 폭을 넓히고 서로배워가며 완성해나가야한다. 

비지니스 전문가 조차 이러한 미팅을 통해 새로운 통찰력을 각게되어야한다.


핵심도메인을 찾아내는데 몇달이걸리는것이 아닌 몇시간이면 충분하고, 잘못된것은 빠르게 구겨서 버리면된다.

이 와같은 이상에 도전하기 위해  DDD에서 제안하는 몇가지 유용한 구체적인 방법을 살펴보자

이벤트 스토밍

사용되는 포스트잇


이벤트

과거형

명령
이벤트
발생		수행자
책임자


작성순서

이벤트 작성

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

명령정의

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

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

Story Mapping

정리할것....

Example Mapping

정리할것....


SWOT 분석사용

우리의 DDD가 잘 수행되는지 어떻게 알수 있는가? 스프린트가 끝나게 되면

회고를 통해서 현재의 시스템및,개발 프로세스를 포함 문화를 지속 개선해 나가야한다.

여기에 소개한 방법들은 여러가지 이유에의해서 맞지 않을수 있다. 그중하나는 개발수준 또는 프로덕트에서 바라보는

개발의 관점등일수도 있다. 중요한것은 처음부터 높은 개발수준으로 시작하는것이 아니라 유연하게 문화를 개선해가면서

개발수준또한 점진적으로 발전시키는것이다. DDD를 깊게 공부하다보면 꽤 높은 수준의 OOP능력을 요구한다. 


마무리

발견해야하고 정해야할내용이 무엇인지에 따라 위에 소개된 방법을 적절하게 사용하면된다.

기획문서와 분석문서가 필요없었던 , 필자의 실제 글로벌 프로젝트 경험상 위 기법들은

시행착오를 빨리하여, 작은 실패를 허용하는 조직의 문화였다. 

  • Story Mapping : 프로덕트 요구사항 나열 할때
  • 이벤트 스토밍 : 프로덕트 요구사항을 분석할떄
  • Example Mapping : 실제 어떻게 작동되는지 
  • SWOT : 스프린트가 끝날때마다 , 모든것을 점검(회고)하고 다음 스프린트에 영향을 줌


참고자료




  • No labels