저자는 종이에 인쇄된 전체 클래스 다이어그램을 봤었음. 하지만 이를 봤을 때 각 객체를 자연스럽게 구분 짓는 경계가 거의 없었음
→ 결론: 기본적인 수준에서조차 모델은 구현에 지침을 제공하지 못함
그래서 개발자는 자기가 즉흥적으로 설계를 만들어 나감.
이렇게 하다가 결과물을 보니 기존 애플리케이션의 설계는 분명 어떤 주목할 만한 일반화나 추상화 없이 기존 코드 위에 다른 기능을 더하는 식으로 구현이 되었음.
→ 구성은 갖췄지만 이해하기 어려움
→ 유지보수 불가…
따라서 설계의 기반이 되는 모델이 필요함. 이제 도메인 주도 설계에서 필요로 하는 모델링 접근법을 보자.
코드와 그것의 기반이 되는 모델이 긴밀하게 연결되면 코드에 의미가 부여되고 모델과 코드가 서로 대응하게 된다.
도메인 몯레은 전혀 없고 기능만 차례로 구현하기 위해 코드를 적성하는 프로젝트에서는 앞서 두 장에 걸쳐 논의한 지식 탐구와 의사소통의 이점을 거의 살리지 못함. 도메인이 복잡하다면 이러한 프로젝트는 난관에 처할 것.
한편으로 여러 복잡한 프로젝트에서 도메인 모델을 시도해도 모델과 코드가 긴밀하게 연결하지 못함