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

Compare with Current View Page History

« Previous Version 12 Next »

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

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

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


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

  • 애자일 : 예측 불가한 도메인때문에 ,프로젝트의 라이프 사이클을 짧게하여,지속 수정 가능한 유연한 개발방법 도입
  • DDD : 오늘날의 소프트웨어 복잡성은 기술보다 도메인의 복잡성및 변화에 기인하며 도메인을 중심에둔 현명한 개발방법 도입

이야기하는 패러다임은 완전하게 다르나,변화하고 복잡해지는 비지니스 모델에 대응하기위해

어떠한 개발 문화를 가져야할까? 고민하는 부분은 동일하며  목표 달성을 위해 사용하는 도구 또한 상당수 공유하고 있습니다.

애자일이 주로 개발문화에대해 영향을 주었다고하면, DDD는 개발자가 구체적으로 구현해야할 구현체까지 이야기하고 있습니다.



DDD가 애자일과 다르게 추가적인 특이점이 있다고하면, DDD를 위한 구체적인 구현방법이 존재합니다.( ex> 애자일 구현편은없으나, DDD 구현편은 존재함 )

경계해야할것

작업셔플

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

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


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

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

이것은 변화와 지속개선을 추구하는 애자일이 추구하는 방향및 DDD의 방향 또한 아닐뿐더러 아마 우리가 원하는 방향도 아닐것이다.


UML/다이어그램

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

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

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


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

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

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

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

도전 

필자의 뇌피셜이 충만하기때문에

태클없는 분만 열어보기를 권장합니다.

기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초  퍼펙트한 기획문서는 존재할수 없다란

명제를 가지고 빈번하게 발생하는 시나리오를 예를 들어보겠다.


기획과정에서 공유되지 않는 잘못된 모델이 (모델이 아니고 정확하게는 심혈을 기울인 UX이다.)

비지니스 모델을 반영을 하지 못한채 오랫동안 묵혀서 기획 완성본에 들어가 숨어있으며

언젠가 기획문서가 완성되어 개발시작가능합니다란 소식을 듣게 됩니다.

개발자는  장대한 기획서에서 틀린 그림찾기를 시작하고 만약 이것을 빨리 찾지못한다고하면

잘못된 채로 작동하게되며, 심각한 경우 그것이 왜 잘못인지 알지못한채 마법의 기능이 될수도 있다.


폭포수 모델에서 이것은 기획(BA포함)의 잘못으로 돌려야만 하고 개발자의 노력을 퍼붓는것으로 해결가능하기때문에

기획은 도움이 별로 안되고,개발자만이 최종 해결자란 인식이다.  필자의 경험상 위와같은 문제는 항상 발생하였다.

기획서를 보면 준수해야한다란 생각보다  잘못된것을 당연하게 개발자가 찾아야하는것이고

잘못된 기준은 비지니스 전문가를 배제한체 변경이 일어난다란것이다. 뭔가 잘못되지 않았는가?

더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),대부분의 노력을 UX를 그리는데 사용하는것을 봐왔다.

상상력을 캔버스에 그려야하는 기획자는 디자이너인가? 기획을 빨리 적용하려고 완료사항을 체크하는것은 PM인가?

IT에서 기획자 롤이 점점 모호해지는것은 사실이다.


그리고 모호해진 기획의 롤은 디자이너가 아닌 비지니스 분석가에 가깝다(https://brunch.co.kr/@hyunda/33)

그렇다고 DDD에서는 어떠한 롤을 지정하지 않는다. 모두가 도메인 모델분석을 위해 소통을 해야한다란것을 강조하고

구체적인 몇가지 방법들이 존재하고 계속 변화중에 있다.


DDD에서 이것은 누구탓도 아니다. 비지니스 전문가와 소통하지 않으며 진행되는 개발과정 자체와

그렇게 개발된 자산(개발코드)에서 도메인에 대한 어떠한 통찰력을 알아낼수 없다는것을 지적합니다.

DDD는 다음과 같은 질문을 던집니다.

나만 알고 있는것이 무엇이고? 당신은 무엇을 알고? 우리는 무엇을 같이 알고 있고 무엇을 알아내야만 하는가?


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


이벤트 스토밍

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

개발자라고 하면, 잠시 개발자임을 잊자~ 개발전문 용어는 아무런 도움이 되지 않는다.

사용되는 포스트잇

이벤트

과거형

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


작성순서

이벤트 작성

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

명령정의

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

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

Story Mapping

아래링크 참고 ( 애자일 열풍때 주로 생겨난 방법으로 한글자료도 다수 )

Example Mapping

아래링크 참고

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

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

SWOT 분석사용

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

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

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

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

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


마무리

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

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

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

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


참고자료




  • No labels