문제-인지
우리가 가진 소프트웨어가 왜 복잡해지고, 통제가 안되는지? 문제에 대한 인지로 도메인 주도 설계(이하 DDD)의 이야기는 시작합니다.
나쁜 설계
우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며
할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고
나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다.
이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.
좋은 설계의 다음 대안은 나쁜설계이다. 이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.
설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하며 비지니스 문화가 확고한 경우 설계문화가
생길수 없다란것을 강하게 경고하고 있다.
큰 진흙 덩어리
여기서 큰 진흙 덩어리는 , 여러개의 비지니스 모델이 하나의 서비스에 뭉쳐 작동되는 솔리드 시스템 자체에 대해 문제를 말하는것이 아니다.
비지니스 모델의 특성과 작동방식을 구분짓는 경계가 어떠한 형태로든 존재하지않거나, 파악되지 않는 자체의 현상이된 문제이며
이것은 비지니스 로직이 생길때마다, 프로젝트 예측을 매우강하게 요구하여 설계에 들이는 노력이 소프트웨어가 지연되는
결과로 이어질수 있기때문에 개발팀은 심사숙고한 설계보다. "작업셔플"만을 사용을하여 점점 큰 진흙덩어리를 만들어 내고 있다란 것이다.
이렇게 거대해진 덩어리는, 문제해결을 위해 두더지 한마리를 겨우 잡으면, 다른곳에서 또 두더지가 나타나는 두더지 게임이 되는 상황을 예고하고 있다.
큰 진흙덩어리를 이해하기 위한 그림
이러한 덩어리가 되는것에 대한 원인은 비지니스모델 자체의 변화와 복잡성때문이며
도메인을 소프트웨어 개발 중심에 놓아야한다라고 이야기를 합니다.
도메인의 복잡성 다루기
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기로 시작이 됩니다.
DDD의 적용은 우리에게 상처를 줄까?
도전-전략적 설계
모델
모델을 만들거나 이용하는것은 우리 생활속의 일부이다. 레고를 만드는것, 보드게임을 하는것
소프트웨어에서도 도메인을 분석하여 모델을 만드는일은 늘 해오던일이다. 하지만 우리는 이러한 모델을 만드는것에대한 노력을 하지않고 있으며
'분석을 위한 모델' , '설계를 위한 모델' 이분법에대해서도 경고를 하고 있다.
이분법을 채택하면서 결국 실제코드와 처음 구상된 모델에 간격이 벌어지면서 모델에 내재된 도메인을 잃게된다는 것이다.
모델을 만드는 과정은 도메인전문과와 팀의 합의된 방식으로 완성된 코드 자체가 모델을 반영해야한다란것이다.
모델링의 표현방법으로는 개발자만 사용가능한 전문적인 다이어그램일 필요가 없다. 모델은 다이어그램 자체가 아니라,
그것을 전달하고자 하는 아이디어이기때문이다.
예> 화물의 이동에따라 , 화물에대한 책임변화를 나타낸 모델
위와같이 자연어와 함께, 전달하고자 하는 아이디어에 대한 그림한장 이면 충분하며, 도메인 전문가와 지속적인
모델을 만들어내는것에대해
