Page History
| Info |
|---|
도메인주도 개발(DDD) 가속화를 위한 도구와 방법을 살펴보자 잘 구성된 팀은 모델링할 때 필요하다면 무슨 도구든지 사용할 필요가 있지만 이것을 가지고 거대한 연회는 하지말자 DDD에서는 문서가 대화를 지배하는 상황을 경계해야할 대상으로 언급하고 있습니다. 모두가 동의할수 없으나, 간단하게 애자일과 DDD를 한문장으로 정의해보자
이야기하는 패러다임은 완전하게 다르나,변화하고 복잡해지는 비지니스 모델에 대응하기위해 어떠한 개발 문화를 가져야할까? 고민하는 부분은 동일하며 목표 달성을 위해 사용하는 도구 또한 상당수 공유하고 있습니다. 애자일이 주로 개발문화에대해 영향을 주었다고하면, DDD는 구현코드에서 도메인의 특성이 나타나야하며,구체적인 구현편으로 이어집니다. ( ex> 애자일 구현편은 없으나, DDD는 구체적인 구현편이 존재함 ) |
...
비지니스 전문가를 프로젝트 초기에 참여시킬수 있는 방법이 필요하며 화이트 보드와 포스트잇이면 충분하다.
프로젝트 초기 핵심 도메인 발견에 혼자만의 심오한 생각이 깃든 기획문서, 화려한 목업 UI, 거창한 UML등 과감하게 버리자
핵심 도메인을 발견하고 가속화하는데 걸림돌이 될뿐이다.
모델링은 전문적일 필요가 없으며 그것을 전달하고자 하는 아이디어이면 충분하다.
...
도전과제
툴설명과는 상관없으며 필자의 뇌피셜이 충만하기때문에
필자의 뇌피셜이 궁금하거나 , 태클없는 분만 열어보기를 권장합니다.
| Expand | ||
|---|---|---|
| ||
기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초 퍼펙트한 기획문서는 존재할수 없다란 명제를 가지고 빈번하게 발생하는 시나리오를 예를 들어보겠다. 기획과정에서 공유되지 않는 잘못된 모델이 (모델이 아니고 정확하게는 심혈을 기울인 UX이다.) 비지니스 모델을 반영을 하지 못한채 오랫동안 묵혀서 기획 완성본에 들어가 숨어있으며 언젠가 기획문서가 완성되어 개발시작가능합니다란 소식을 듣게 됩니다. 개발자는 장대한 기획서에서 틀린 그림찾기를 시작하고 만약 이것을 빨리 찾지못한다고하면 잘못된 채로 작동하게되며, 심각한 경우 그것이 왜 잘못인지 알지못한채 마법의 기능이 될수도 있다. 폭포수 모델에서 이것은 기획(BA포함)의 잘못으로 돌려야만 하고 개발자의 노력을 퍼붓는것으로 해결가능하기때문에 기획은 도움이 별로 안되고,개발자만이 최종 해결자란 인식이다. 필자의 경험상 위와같은 문제는 항상 발생하였다. 기획서를 보면 준수해야한다란 생각보다 잘못된것을 당연하게 개발자가 찾아야하는것이고 잘못된 기준은 비지니스 전문가를 배제한체 변경이 일어난다란것이다. 뭔가 잘못되지 않았는가? 더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),대부분의 노력을 UX를 그리는데 사용하는것을 봐왔다. 상상력을 캔버스에 그려야하는 기획자는 디자이너인가? 기획을 빨리 적용하려고 완료사항을 체크하는것은 PM인가? IT에서 기획자 롤이 점점 모호해지는것은 사실이다. 그리고 모호해진 기획의 롤은 디자이너가 아닌 비지니스 분석가에 가깝다(https://brunch.co.kr/@hyunda/33) 그렇다고 DDD에서는 어떠한 롤을 지정하지 않는다. 모두가 도메인 모델분석을 위해 소통을 해야한다란것을 강조하고 구체적인 몇가지 방법들이 존재하고 계속 변화중에 있다.
|
...