概念完整性
Brooks在他的經典鉅著《人月神話》裏面提到了概念完整性，並將軟件維護軟件的 “概念完整性” 作爲軟件開發的核心問題。軟件工程之所以複雜、難以維護，根本原因在於軟件迭代過程中概念完整性遭到了破壞。軟件開發者不理解原先開發者的設計理念，對軟件領域模型不足夠了解，團隊內部缺乏溝通和可維護性文檔，甚至開發團隊從來就沒有意識到維護軟件概念完整性的重要性。這羣開發者從一定程度上講，他們不算是一個團隊，他們只是聚集在一定空間，時間範圍內一起堆疊代碼的孤島程序員。
從模型分析到設計
以業務領域爲中心，對於軟件開發來說是極爲重要的。我們說過，最重要的是，創建一個植根於領域、並精確反映出領域中的基本概念的模型。通用語言應該被充分運用在建模過程中，以推動軟件專家和領域專家之間的溝通，以及發現應該被用在模型中的關鍵領域概念。建模過程的目的是創建一個優良的模型，下一步是將模型實現成代碼。這是軟件開發過程中同等重要的一個階段。創建了一個優良的模型，但卻未能將其成功地轉換成代碼將會得到質量有問題的軟件。
任何領域都能被表達成多種模型，每一種模型都能以不同的方式被表現達代碼。擁有一個在分析層面正確的模型，並不代表模型能被直接表達成代碼。或者它的實現會違背某些軟件設計原則，這是我們不建議做的事情。選擇一個能夠被輕易和準確地轉換成代碼的模型是很重要的。根本的問題是：我們應該如何完成從模型到代碼的轉換。
一個推薦的設計技術是創建分析模型，它被認爲是與代碼設計相互分離的、通常是由不同的人完成的。分析模型是業務領域分析的結果，此模型不需要考慮軟件如何實現。這樣的一個模型可用來理解領域，它建立了特定級別的知識，模型在分析層面是正確的。軟件實現不是這個階段要考慮的，因爲這會被看作是一個導致混亂的因素。分析人員可能會過多深入到模型中某些組件的細節，但其他的部分卻缺乏足夠的細節。非常重要的細節直到設計和實現過程才被發現。設計階段，開發人員不得不修改它，或者創建分離的設計。在模型和代碼之間也不再存在映射關係。最終的結果是分析模型在編碼開始後就被拋棄了
解決模型分析、設計一致性
1、加強分析人魚、軟件專家、領域專家內部的溝通交流。模型中的一些細節不容易表達爲圖形的形式，甚至也可能無法完全用文字來表達。開發人員理解這些細節非常困難。在某種情況下他們會對想要的行爲做出一些假設，而這些假設有可能是錯誤的，最終會導致錯誤的程序功能。
2、舉行團隊領域模型相關內部會議，推動開發人員積極參與，開發人員如果能夠參加分析討論會議，並在開始做編碼設計之前對領域和模型獲得一個清晰完整的視圖，他們的工作將會更有效率。
3、一種更好的方法是將領域建模和設計緊密關聯起來，開發人員應該被加入到建模的過程中來。有了開發人員的參與，就會獲得反饋，它能確保模型能夠在軟件中得到實現。寫代碼的人應該很好地瞭解模型，應該感覺到自己有責任保持它的完整性。從模型中提取出在設計中使用的術語和所分配的職責之後，代碼就成了模型的表達方式，所以對代碼的一個變更就可能成爲對模型的變更。變更的影響相應地還會波及到項目的其餘活動中
4、及時反饋軟件設計的變更，以更好的模型設計決策，以及領域模型正確性的評估。如果哪裏的代碼不能表達最初模型的話，他們將會對代碼做重構。如果分析人員從實現過程中分離出去，他會不再關心開發過程中引入的侷限性，最終的結果是模型將不再適用。如果設計或者設計中的核心部分沒有映射到領域模型，模型就沒有什麼價值，而軟件是否正確也就令人懷疑。同時，模型和設計功能之間的映射如果很複雜，就會很難理解，當設計變更了實際上模型是不可能維護的。分析和設計之間出現了致命的割裂，這樣一個活動（分析或設計）中產生的想法將無法對另外一個產生影響
5、將設計工作交給實施開發者，避免設計設施分離。國內盛行一些相對不良作風，出現不寫設計，不參與實施工程師。軟件設計是一個有着衆多不可預見性並持續變化的工程，實施階段發現設計，甚至模型分析不合理性難以避免。如果將設計工作交於基層工程師，可以更好的避免代碼、模型不匹配。當然，對於初級工程師，應該加強幹預設計，但不應該完全脫離實現