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

Compare with Current View Page History

« Previous Version 28 Next »

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

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

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

DDD 복습

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

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

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

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


애자일이 주로 개발문화에대해 영향을 주었다고하면, DDD는 구현코드에서 도메인의 특성을 반영해야하는것을 중요하게 생각하며,구체적인 구현편으로 이어집니다.

애자일또한 이러한 구현에대해 중요하게 생각하고 있었으나 구체적으로 정리된 버전은 존재하지 않습니다.

그러한 의미에서 애자일의 연속성에서 DDD는 중요한 의미를 가집니다. DDD의 구현편은  다양한 프레임워크에서 구현편이 존재하며 마이크로 서비스에서도 DDD가 적용되고 있는 추세입니다. (국내는 제외)

정작 마이크로서비스,쿠버네틱스등 국내에서도 인프라적인 이야기는 많이 되고 있으나  마이크로 서비스 구현체에 활용될수 있는 DDD의 자료가 거의 없거나 정착이 되지 못하는것은 다소 안타깝습니다. 

웹영역에서는 OOP를 개발자의 기술적 역량 파악하는데만 사용 되어왔으며  EJB/컨테이너/컴퓨넌트 모델방식으로 어디에 코딩해야하는지만 신경을 쓰게되었으며

개발자는 OOP능력을 대부분 상실해 갔습니다. 결국 이것은 도메인 모델링자체가 실종하는 결과가 되었으나 그래도 작동해 왔습니다. 

그동안 객체지향 사상을 기업 규모 어플리케이션이 어떻게 적용할지에 대해 분명한 비전이 없었다란점을 감안하면 

DDD는 비지니스 문제 해결을 위해 OOP의 능력을 활용하고 구현체를 제안 하고 있으며 , 이러한 이유로 DDD는 엔지니어 개발자로서 중요하다고 생각합니다. 

구현없이 클릭만으로 모든 비지니스 모델을 만들수 있는 그런시대가 분명 올지도 모르지만 

DDD는 생소한것이 아니고, 이제는 다양한 웹프레임워크에 녹여있으며 쉽게 검색가능합니다. (국내 적용사례는 거의 없음)

( MVC가 그래왔던 것처럼 빠르게 뿌리내리지는 못할것같으나 언젠가는 국내에서도 활용하는 기업이 생겨날것으로 기대해봅니다.)

경계해야할것

작업셔플

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

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


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

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

UML/다이어그램

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

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

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

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

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

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

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

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

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

도전과제

툴설명과는 상관없으며 필자의 뇌피셜이 충만하기때문에

필자의 뇌피셜이 궁금하거나 , 태클없는 분만 열어보기를 권장합니다.

여기서 언급되는 시나리오는 지난15년간 다녔던 모든회사에서 동일하게 경험한 내용을 바탕으로

가상화한 내용이며 지극히 개인적인 경험과 생각이 포함된 뇌피셜임을 먼저 알려드립니다.


기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초  퍼펙트한 기획문서는 보지못하였다.

최신 완성품의 내용을 반영하는 기획서 또한 보지 못하였다. 기획서에는 내가 궁금한 내용이 없을뿐더러,

심지어 작동방식을 반대로 설명하는 경우도 있다. 작동기준으로 기획서를 반대로 다시 업데이트하는것 또한 웃긴일이다.


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

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

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

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

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


폭포수 모델에서 이것은 개발자의 노력을 퍼부어 해결해 왔기때문에, 당연하게 기획의 잘못으로 돌려야만 했고

기획은 도움 안되고,개발자만이 최종 해결자란 인식이다.  필자의 경험상 이와 같은 문제는 항상 반복되어왔다.

기획서를 보면 비지니스 요구사항을 분석하여 반영되었기때문에 준수해야한다란 생각보다   

비지니스 요구사항이 존재하기나 한가? 한심한 기획서를 많이 봐왔다. 더 잘못된것은 비지니스 전문가를 배제한체,

개발자 해석으로 변경이 일어나고 타협을 한다란것이다.  뭔가 잘못되지 않았는가?


더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),이제는 비지니스 요구사항보다

화려한 UI(목업)을 그리는데 능력을 사용하기 시작하였다. 기획서를 보고해야하기 때문이다.

그리고 최근 목업툴의 발전으로 심지어 프로튼 화면 수준까지 UX가 작동되기까지 한다. 


물론 디자인이 중요할때 UX및 레이아웃을 포함 그것 자체를 기획하는 롤이 있고 중요할수도 있습니다.

DDD에서는 어떠한 롤을 누군가가 해야한다란것을 이야기하지 않습니다. 비지니스 전문가,분석가,개발자 개발에 참여한 모든 사람의 소통을 중요하게 생각합니다. 

만약 기획롤이 불분명하다고 하면, 디자이너보다 BA의 역활에 가까운것이 또는 커뮤니케이션을 통해  마법과같은 비지니스의 본질을 파악하여

개발자에게 전달할수 있는 역활에 가까워야 한다란것이 저의 생각입니다.

DDD는 단 한문장으로 이것을 이야기 합니다.  "문서가 대화를 지배해서는 안된다."

참고자료 : BA의 역활 https://brunch.co.kr/@hyunda/33

DDD에서 이것은 누구탓도 아니다. 다음과 같은 질문을 모두에게 던진다.

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

그리고 이 과정은 모험과 같아서 끊임없는 탐구라고 정의를 내립니다.

DDD 도입은 해결책이 아닌 해결책을 찾기위한 과정입니다.  그리고 성공/실패라고 정의내리기도 어렵습니다.



DDD가 이야기하는 핵심은 

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


이벤트 스토밍

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

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

핵심 도메인 이벤트를 찾는데 방해가 된다. 이과 정에서 개발 전문 용어가 단한번이라도 나오면

비지니스 전문가의 도움을 받는것을 포기하라, 비지니스 전문가에게  ORM에서 N+1의 문제가 무엇인지 10초만에 설명을 할수있으면 그래도 좋다.

그리고 이벤트를 나열하는 단계에서,제약 사항을 예측하면서 초반에 이야기를 끊는것또한 경계해야한다.

이야기를 많이 끊는 것은  대부분 도메인에 자신있다고 여기는 개발자가 대부분 하게되며 

필자또한 그랬던적이 있으며 돌이켜보면 대부분 무례했던것같다. 이러한것이 한번 시작되면 

도메인 이벤트 아이디어를 수집은 커녕.. 올바른 순서대로 나열하는것은 불가능하다.

중복을 제거하고 중요하지 않은것은 제거하고 진행방법은 아래에 설명된 규칙을 참고하여 진행하면된다.

이와같은 방법은 커뮤니티에 대한 수준을 높이는것이 포함되어 있다. 겸손/경청이 중요함을 다시한번 강조

사용되는 포스트잇 색상

작성순서

이벤트 작성

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

명령정의

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

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

Story Mapping

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

Example Mapping

아래링크 참고

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

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

SWOT 분석사용

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

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

이러한 방법들을 사용하더라도 DDD도입은 여러가지 이유에 의해 맞지 않을수 있다.

그중 하나는 개발수준 때문 일수도 있고 이것을 사용할 개발문화가 준비때문일수도 있고

이것을 운영할 전문가가 없거나, 수직적 워터폴 개발문화가 더 맞을수도 있기때문이다.


마무리

DDD는 특정 한명이 공부하여 시작할수있는 스케일은 결코 아니다.

모두가 공부해야하며 시행착오를 통해 서로에게 또 배워야하는 내용이다.


여기서 소개된 도구가 어떻게 활용이 되는가 간단하게 요약하며 마친다.

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


참고자료




  • No labels