Page History
...
결과로 이어질수 있기때문에 개발자는 심사숙고한 설계보다. 위에서 언급한 "작업셔플"만을 사용을하여 적절한 분리된 모델이 아닌 큰 진흙덩어리를 빨리 만들어 내고 있다란 것이다.
이렇게 거대해진 덩어리는, 문제가 되는 문제해결을 위해 두더지 한마리를 겨우 잡으면, 다른곳에서 또 두더지가 나타나는 두더지 게임이 되는 상황을 예고하고 있다.
그리고 이렇게 되는 원인은 기술의 복잡성이 아닌 비지니스 모델자체가 복잡하기때문이다라고 이야기를 하며
...
우리가 가진 도메인 자체의 복잡성에 기인하며, 이렇게 큰 진흙덩어리가 된 되어가는 이유는
비지니스 전문가의 이야기를 귀를 기울이지 않은채 소프트웨어 팀이 제멋대로 노력한 결과라고 경고를 합니다.
그리고 이러한 복잡성을 다루기위해 도메인 전문가를 참가시켜 경계를 구분하고,언어를 통합하고 전략적으로 모델을 만드는 도전과제에 대해
이야기가 이어집니다.
도전-전략적 설계
모델
모델을 만들거나 이용하는것은 우리 생활속의 일부이다. 레고를 만드는것, 보드게임을 하는것
소프트웨어에서도 도메인을 분석하여 모델을 만드는일은 늘 해오던일이다. 하지만 우리는 이러한 모델을 만드는것에대한 노력을 하지않고 있으며
'분석을 위한 모델' , '설계를 위한 모델' 이분법에대해서도 경고를 하고 있다.
이분법을 채택하면서 결국 실제코드와 처음 구상된 모델에 간격이 벌어지면서 모델에 내재된 도메인을 잃게된다는 것이다.
모델을 만드는 과정은 도메인전문과와 팀의 합의된 방식으로 완성된 코드 자체가 모델을 반영해야한다란것이다.
모델링의 표현방법으로는 개발자만 사용하는 전문적인 다이어그램일 필요가 없다.
모델은 다이어그램 자체가 아니라, 그것을 전달하고자 하는 아이디어이기때문이다.
예> 화물의 이동에따라 , 화물에대한 책임변화를 나타낸 모델
위와같이 자연어와 함께, 전달하고자 하는 아이디어에 대한 그림한장 이면 충분하다.