每個軟件架構師，開發經理和開發人員都很可能遇到過軟件設計和開發中“自上之下vs.自下而上”的爭論。

正確的答案其實是，這里并沒有單一的最佳方案。 應用是用自上而下和自下而上的兩種方案之一來構建，每種方式的支持者和另一方的支持者一直爭論不休。但是決定企業應該采取哪一種應用開發戰略要求檢視需求和資源，并且考慮到應用可能的變化，理解應用設計上這兩種不同的方案以及各自減少風險的所需步驟。

模塊化編程理念和企業架構都影響著軟件開發，使其從上開始，從業務需求和預期收益入手。

實際上，這意味著列出業務目標，基于映射到用戶行為的功能劃分，用通用的軟件術語來描述業務目標，然后將這些功能進一步分解，匹配硬件和軟件的需求。在過去的十年里，這已經被廣泛接受成為應用程序設計的最佳方法。

自上而下和自下而上

自上而下應用設計和開發也更容易和企業以及將使用應用的用戶相匹配。大家理解軟件做什么以及怎么做，意味著他們從應用的功能驅動視圖來理解應用。如果從這樣的視角開始，就可以從業務部門收集方案使用性方面的需求，并且能夠洞察出業務實踐隨時間的改動可能會如何影響到軟件設計。

這樣自上而下方案的問題在于，項目目標還包括使用某種特定技術或者資源集——特別是云——的時候會遇到問題。應用不會為云自動優化；他們必須特別設計來利用云的特定特性，同時避免花費過多。從上開始的話，架構師可能能夠構造出一些和一開始的目標平臺以及托管選項不是特別匹配的東西。自下而上的方案才能夠確保托管以及資源的正確使用。

自下而上的應用開發戰略更容易契合通過面向服務架構或者微服務的使用而開發的組件庫。如果可以從已有軟件組件組裝出一個應用程序——或者其中的一大部分——那么就可以減輕開發負擔和應用生命周期管理需求。自上而下方案在現有組件模型沒有什么用時可以領導設計的方向。

經驗豐富的開發團隊已經適應了自上而下vs自下而上的應用開發戰略之爭，但是有兩種基礎方案得到了廣泛認可。一種著重考慮資源或者平臺目標，認為這些和功能需求一樣重要，另一種更像是“在中間會和”的方案。

很容易看出，如果需要為使用現有模塊化模型而進行優化，或者為云計算做準備，這樣的需要提升成為需求時，那么應用程序設計需要從一開始就考慮到這些需求，并且按需作出設計。但是，不是所有開發團隊都能夠輕松在設計的最高層混合功能和技術的需求。使用云技術如何和支持某種特定的功能行為相契合呢？如果無法回答這個問題，那么流行的做法是設置某個需求集的優先級高于另一個需求集。這樣能夠完成擁有有限功能的設計。

當基于資源，平臺或者組件重用的目標，業務需求適合某個假定的應用模型時，“提升”模型能夠工作得很好。比如，一個基本的Web前端軟件模型，管理特定的系統-用戶關系，鏈接到一系列解決企業功能需要的應用流程上，能夠足夠好地組織開發工作，確保重用需求可見，而不犧牲任何功能性。

“在中間會和”方案假定平臺和組件創建一個能夠抽象到一系列技術行為的工具包。比如，可用組件能夠組裝起來更新數據庫或者完成報告。這些高層級的行為也能夠關聯到云特性上，比如水平擴展或者故障發生時的實例置換。雖然它們可能無法直接映射到新應用的功能性需求——或者它們可能對于項目而言并不需要——它們比基礎技術需求更加功能化。架構師隨后就能夠基于這些行為組合出第二或者第三層設計。

基于行為，在中間會和的應用開發戰略的問題是，如何向上反應行為感知性，而不會被底層問題占據。最佳方式是從底層開始組裝有用的行為，然后將其暴露成工具給架構師，架構師從頂層開始功能性設計。該方案在有顯式高層功能性需求時最有用，這些需求可能來自一個良好的EA模型。沒有非常強有力的功能性需求，那么設計流程就很容易被自下而上的資源探求和組件戰略所占據。

自上而下的設計很好地將應用和業務目標契合在一起，并且優化用戶體驗的質量，但是他們可能創建出不是最優的組件化，并且限制了應用程序采納新技術，比如云計算的能力。自下而上的設計優化資源和組件化能力，但是可能會偏離用戶的體驗質量。最后，最好選擇契合你的最重要目標的方案，然后一步步確保能夠兼顧到另一端。