Page History
...
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하며 비지니스 문화가 확고한 경우 설계문화가
생길수 없다란것을 강하게 경고하고 경고도 하고 있다.
큰 진흙 덩어리
여기서 큰 진흙 덩어리는 , 여러개의 비지니스 모델이 하나의 서비스에 뭉쳐 작동되는 솔리드 시스템 자체에 대해 문제를 말하는것이 아니다.
비지니스 모델의 특성과 작동방식을 구분짓는 구분하는 경계가 어떠한 형태로든 존재하지않거나, 파악되지 않는 자체의 현상이된 문제이며
이것은 비지니스 로직이 생길때마다, 프로젝트 예측을 매우강하게 요구하여 설계에 들이는 노력이 소프트웨어가 지연되는
결과로 이어질수 있기때문에 있다라는 의식과 함께, 개발팀은 심사숙고한 설계보다. "작업셔플"만을 사용을하여 점점 큰 진흙덩어리를 만들어 내고 있다란 것이다.
이렇게 거대해진 덩어리는, 문제해결을 위해 두더지 한마리를 겨우 잡으면, 다른곳에서 또 두더지가 나타나는 두더지 다음과같이 두더지 게임이 되는 상황을 예고하고 있다.
큰 진흙덩어리를 이해하기 위한 그림
진흙덩어리에서는 두더지 한마리 잡으면 , 예측하지 못하는 다른곳에서 두더지가 또 발생하는 상황에대해
설명을 하고 있다. 이러한 덩어리가 되는것에 대한 원인은 비지니스모델 자체의 변화와 복잡성때문이며
도메인을 소프트웨어 개발 중심에 놓아야한다라고 이야기를 합니다중심에 놓고 복잡성을 다뤄야 한다라고 이어집니다.
도메인의 복잡성 다루기
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성이 복잡성 때문이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기로 시작이 됩니다.
DDD의 적용은 우리에게 상처를 줄까?
DDD의 접근 방식은 소프트웨어의 복장성을 이기기 위해 무엇이 필요하고 어떻게해야하는가?
이것을 해결 하기위한 기술은 무엇이고? 우리의 기술수준은 어떠한가? 라는 물음이자 그것을 해결하기 위한 노력이다.
그리고 좋은 소식은 소프트웨어 복잡성을 다루기 위해 다양한 개발진영의 프레임워크에 그것을 활용한 구현체가 등장하기 시작한것이다.
여러분이 사용하는 프레임워크에 "~ with ddd" 라는 검색을 시도해보기 바란다.
분명 학습곡선이 높고 지금 당장 적용하기는 어렵겠지만, 적어도 기존과 사용하던 방식보다 수준높은 방식이 사용됨을 알수가 있다.
도전-전략적 설계
모델
모델을 만들거나 이용하는것은 우리 생활속의 일부이다. 레고를 만드는것, 보드게임을 하는것
소프트웨어에서도 도메인을 분석하여 모델을 만드는일은 늘 해오던일이다.
하지만 우리는 이러한 모델을 만드는것에대한 노력을 하지않고 있으며 있으며, 인지하지 못하는경우도 있다.
또한 '분석을 위한 모델' , '설계를 위한 모델' 이분법에대해서도 경고를 하고 있다.
...
위와같이 자연어와 함께, 전달하고자 하는 아이디어에 대한 그림한장 이면 충분하며, 도메인 전문가와 지속적인
모델을 만들어내는것에대해 만들어내는것에대해 다음과 같이 설명을 한다.
- 개발자와 도메인 전문가 모두 문서가 대화를 지배하는 상황을 피해야한다.
- 최고의 보편언어는 서로 협업하며 나오는 피드백에의해 만들어진다.
- 이 과정에서 팀의 화합된 멘탈 모셀을 만들수 있으며, 이러한 지식탐구는 도메인에대한 통찰로 이루어진다.
이벤트 스토밍
덩어리를 나누기
...
도메인 전문가와 개발자가 어떻게 같이 참여를 하여, 전략적 설계를 효율적으로 할것인가에 대한 방법중 하나로
이벤트 스토밍이 소개되고 있다.
- 시간이 지남에 따라 발생하는 이벤트를 과거형으로 나열
- 개발적요소(클래스,데이터베이스)가 아닌 이벤트와 비지니스 프로세스에 집중
- 팀은 이해의 폭을 획기적으로 증신시키고, 비지니스모델을 잘 이해한다고 생각한 전문가도 이해의 폭을 다시 넗히고 새운운 통찰력을 가지게됨
- 모든사람이 무언가를 배우게된다.
참고: 온라인툴도 존재하며 좀더 자세한 활용방법을 알수가 있습니다.