2.1.不斷變化的客戶需求。
2.2.軟體專案無法避免的挑戰。
2.3.產品需求和環境會隨時間而變化，您的應用程式也必須隨之變化。
2.4.不斷變化的需求可能會導致不穩定並破壞開發工作。
2.5.通過構建漸進式架構來適應不斷變化的需求。
2.5.1.進化架構避免了複雜性，而複雜性是進化的敵人。
2.5.2.矛盾的是，在軟體中實現簡單性可能很困難。
3.1.複雜系統的特徵。
3.1.1.高依賴性。
3.1.1.1.該軟體依賴於其他 API 或行為。
3.1.1.2.依賴顯然是不可避免的，甚至是可取的，但它必須是平衡的。
3.1.1.3.依賴性高的系統很難修改。
3.1.1.3.1.它們緊密耦合，具有高度的變化放大。
3.1.1.3.2.緊耦合是指模組之間嚴重依賴，導致更高的變化放大，即需要修改依賴關係的單個變化。3.1.1.4.經過深思熟慮的 API 設計和對抽象模型的克制使用將最大限度地減少緊密耦合並改變放大效應。
3.1.2.隱蔽性高。
3.1.2.1.是什麼讓程式設計師難以進行更改，以及需要更改什麼。
3.1.2.2.晦澀難懂的**需要更長的時間來習，開發人員更有可能無意中破壞某些東西。
3.1.2.3.症狀。
3.1.2.3.1.“知道”太多物件。
3.1.2.3.2.鼓勵 *** 全域性狀態。
3.1.2.3.3.掩碼的過度間接定址 **。
3.1.2.3.4.影響程式遠端行為的遠距離操作。3.1.2.4.採用具有明確約定和標準模式的 API 可以減少模糊性。
3.1.3.高慣性。
3.1.3.1.指軟體保持其以前的習習慣。
3.1.3.2.**用於快速實驗，容易丟棄，慣性低。
3.1.3.3.為十幾個業務關鍵型應用程式提供支援的服務具有很高的慣性。
3.1.3.4.複雜性的成本會隨著時間的推移而增加，因此具有高慣性和高變化的系統應該被簡化，而具有低慣性或變化的系統可以保持複雜（只要你放棄它們或繼續保持它們不變）。
3.2.複雜性並不總是能擺脫它，但你可以選擇把它放在**中。
3.2.1.向後相容的更改可以使它更易於使用，實現起來更複雜。
3.2.2.用於解耦子系統的間接層減少了依賴性，但增加了隱蔽性。
4.1.未知未來的需求策略。
4.1.1.試圖預測未來的需求。
4.1.2.構建乙個抽象模型作為逃生艙口，以便於後續修改。
4.1.3.將導致複雜性增加。
4.2.接吻的原則。
4.2.1.讓事情變得簡單。
4.2.2.使用 KISS 方法，請記住以簡單為核心原則構建系統。
4.2.3.簡單性允許您在未來增加系統的複雜性。
4.3.保持簡單的最簡單方法之一是避免編寫所有內容。
4.3.1.告訴自己你不需要它（yagni）。
4.3.2.使用最小意外原則和封裝原則。
4.4.不要構建你不需要的東西。
4.4.1.通過猜測來編寫將繼續使事情陷入困境，它需要維護，開發人員需要理解它，它必須被構建和測試。
4.4.2.避免過早優化、不必要的靈活抽象模型以及最小可行產品 （MVP） 不需要的產品功能。
4.4.3.過早優化是指開發人員在證明有必要之前優化效能。
4.4.4.靈活的抽象模型 – 外掛程式架構、封裝介面和通用資料結構（如鍵值對）是另乙個模型。
4.4.4.1.抽象是有代價的：它將實現框定在嚴格的邊界中，開發人員最終會與之抗爭。
4.4.4.2.靈活性也使閱讀和理解變得更加困難。
4.4.4.2.1.保持靈活性的最佳方法之一是減少總金額。
4.4.4.2.2.咀嚼方法將使您的軟體保持“纖薄”和適應性強。4.4.5.MVP 允許您首先測試乙個想法，而不必押注於成熟的實現。
4.4.5.1.將介面填充碼放在您懷疑可以插入優化的地方，但實際上並沒有實現它們。
4.5.最小意外原則。
4.5.1.不要讓使用者感到驚訝，構建功能的行為與他們最初預期的一樣，具有公升高的 習 曲線或奇怪行為的功能可能會讓使用者感到沮喪。
4.5.2.不要讓開發人員感到驚訝，令人驚訝的是，他們往往晦澀難懂，這會導致複雜性。
4.5.3.通過保持目標明確、避免隱性知識以及使用標準庫和模式來消除意外。
4.5.4.開發人員在呼叫 API 時需要知道的任何非顯而易見的知識，但不屬於 API 本身，都被視為隱性知識。
4.5.5.對排序的需求決定了某些操作必須按特定順序執行。
4.5.5.1.使用文件來說明一些排序要求是個好主意，但最好一開始就不要有它們。
4.5.6.當方法的簽名意味著比該方法實際可以接受的更廣泛的有效輸入時，就會出現隱藏的引數要求。
4.5.7.請記住，要使您的引數要求具體化和視覺化。
4.5.7.1.使用能夠準確適應約束的特定型別，在使用 JSON 等靈活型別時，請考慮使用 JSON 架構來描述預期的物件。
4.5.8.使用標準庫和開發模式。
4.5.8.1.請使用通常的風格和開發模式。
4.6.包裝領域的專業知識。
4.6.1.將軟體元件對映到業務領域將使變更保持集中和乾淨。
4.6.1.1.會計、計費、運輸等
4.6.2.封裝領域自然傾向於高內聚和低耦合。
4.6.2.1.理想的功能。
4.6.2.2.具有高內聚和低耦合的軟體更有可能發展，因為變化的“半徑”往往更小。
4.6.2.3.解耦**是自包含的，對其邏輯的更改也不需要對其他軟體元件進行更改。
4.6.3.開發人員通常從“層”的角度來考慮軟體：前端、中間層和後端。
4.6.3.1.每一層都有自己的團隊，這增加了編排成本，因為業務邏輯的每次更改都會影響所有軟體層。
4.6.4.識別領域邊界和封裝領域知識既是一門科學，也是一門藝術。
4.6.4.1.領域驅動設計 （DDD），它定義了一組廣泛的概念和實踐，這些概念和實踐將業務概念對映到軟體。
4.6.4.2.只有在最複雜的情況下才需要完全覆蓋 DDD
4.6.4.3.熟悉 DDD 將幫助您做出更好的設計決策。