圖片來源: https://www.tenlong.com.tw/products/9789864348602
第一章講述了軟體發展史中，為了解決軟體開發上的困境許多方法被發明了出來，而雖然每個方法都宣稱能有效解決（或部分解決）專案上的問題，但經過統計，成功的專案始終不超過 22%。而 DDD 也是為了解決軟體開發時所碰到的困境所被提出來的一種方法。
軟體通常是為了解決某些問題而被研發的，所以當錯誤的理解問題就很容易導致失敗，人類在解決問題上有著豐富的經驗，所以當人類看到問題時，通常會有一些直覺的解決方案浮出腦中（快思慢想也有提到這點），這可能源自於你的經驗或是過往學經歷，而這直覺的好點子很高的可能是錯誤的方向，而人往往又會傾向於找盡各種方法試圖說服自己剛剛的好點子是正確的，即便在實作的過程中隱約察覺到不對勁了…
個人經驗中有察覺到這個現象，常常誤以為自己一開始的想法是正確的，所以即便過程中發現問題也會用各種變形方法試圖將問題套入其中，而這往往會將問題變得更複雜。
我曾經跟專案成員討論目前框架使用上的困境，而我發現大部分人會傾向在框架中設計各種 Config 、環境變數切換來滿足所謂的特殊情境，而沒有去思考框架設計是否瞄準錯了問題。又或是為了解決部署環境問題，直接聯想到 Container 解決方案，結果為了管理 Container 所以引入更複雜的 k8s 做為編排的工具，也許本質想解決的問題沒這麼複雜，卻在解決的過程中意外的把問題變得更複雜。
避免無知
書本中將無知分類成五個層級
- 缺少無知(lack of ignorance) : 表示你擁有大部分的知識，知道「該做什麼」、「怎麼做」
- 缺乏知識(lack of knowledge) : 你意識到自己的無知，所以你獲取更多知識來填補知識的落差
- 缺乏意識(lack of awareness) : 「不知道自己不知道」，連意識到無知都沒有，例如拿到規格就覺得自己知道要解決的問題是什麼了，而忽略了其實自己根本不知道本質問題是什麼狀況，人往往會做出錯誤決策都屬這層
- 缺乏流程(lack of process) : 你不知道你自己不知道是什麼，也無管道能弄清楚
- 元無知(meta igonorance) : 連無知的五個層次都不知道
DDD 之父 Eric Evans 對於「提前設計」提出了見解 : 我們在專案的初期會進行提前設計的動作，而此時恰好也是我們擁有「最少知識」並且是最無知的時期。在專案開始時幾乎沒有知識的情況下，就對軟體的設計和架構做出大多數的「重要決策」，這不會是個好的做法。
個人覺得這跟敏捷中提到的小增量多迭代道理是一樣的，我們很難在專案初期就了解問題的全貌，所以小步前進，並且因應碰到的問題即時快速的調整，才能讓我們越來越貼近真實情況的樣貌，也可以降低在專案初期的過度設計，導致架構一直調整的窘境。
隨著現代專案要處理的問題越來越複雜（可能是質或是量的複雜度），有效的處理領域知識、減少無知，準確將問題分類，避免實現目標路途中的認知偏誤，DDD 就是想要解決這些問題所被提出的。