在幾乎每一個軟件設計的基礎上都有一種感知、抽象和分解的方法論。這種理念采用特定的抽象和分解技術將導致更好的設計。在處理變更的場景中，主要有軟件開發的組件方法和服務方法，本文分析了它們在處理變更方面的差異。

1.核心的問題: 需求的改變

對企業而言，應對變化是日常生活中必須加以利用和實現的一個事實。合并、收購和新技術的引入是業務環境變化的驅動因素。業務敏捷性是指企業在不斷變化和不可預測的環境中蓬勃發展的能力。

了解哪些方面更有可能發生變化，哪些方面不會發生變化，對于處理變化至關重要。盡管業務中有許多事情在變化，但有些要素往往保持不變。從中期來看，企業的核心能力相對穩定; 由于業務程序的改變或新技術的采用，企業的運作方式可能受到變化的影響。從長遠來看，業務的幾乎每個方面都可能發生變化。

為了滿足不斷變化的業務需求，軟件系統必須不斷地進化。

業務系統需求變化是軟件設計的一個事實，但并非所有的軟件開發方法都能對其解釋，不同的方法在如何分解系統應對變化方面有著不同的哲學。

在20世紀70年代，結構化分析的發展是為了應對由許多程序員合作開發的復雜系統。結構化分析主要以功能分解為基礎。自頂向下的功能分解從系統的頂層描述開始，然后一步一步地細化這個視圖。通過每次細化，系統被分解成更低級別和更小的模塊。自頂向下分解需要確定主要的系統需求和功能，然后在連續的步驟中分解它們，直到可以設計特定于功能的模塊。

雖然功能分解在較穩定的系統類型方面取得了成功，但在處理業務變化以及隨后的系統維護效率較低。要更改數據結構，通常需要更改與該結構相關的所有函數。因此，系統很容易變得不穩定，因為輕微的修改就會產生嚴重的連鎖反應。

面向對象的范式通過在類中封裝數據及其相應的操作來解決重用和維護問題。問題域中的對象概念比數據結構和函數具有更高的穩定性; 因此系統的整體架構通常是穩定的。此外，面向對象范式的內部細節更改不會擴展到系統體系結構中。

軟件開發方法可以大致分為兩大類: 需求預測方法和需求適應方法。第一種假設在編碼之前可以識別和解決幾乎所有的問題。后者采用了更實用的方法，認為業務系統開發是一個漸進的過程，變更是軟件設計中不可避免的一個方面，預計將在每個階段發生。

為了滿足不斷變化的業務需求，軟件系統必須不斷地進化。因此，軟件開發過程和維護過程之間的分離變得越來越不重要。在這里，支持持續軟件演進有兩種設計方法: 基于組件的開發和基于服務的開發。

2.適應需求的變化: 組件化與服務化

軟件生產的靈活性是技術和非技術因素綜合作用的結果。在處理變更時，組件和服務之間的差異受到這里討論的因素的影響。

2.1 組件：預制組裝

基于組件的開發思想是通過組裝預制軟件組件來生產軟件應用程序，從而實現軟件開發過程的工業化。為了響應變化和不斷變化的需求，基于組件的開發有兩個基本思想。首先，如果可以從預制軟件組件快速組裝應用程序，那么軟件開發可以得到顯著改善。其次，將向開發人員提供越來越多的可互操作的軟件組件，包括一般組件和專業化組件。

2.2 服務：需求與需求實現機制的邏輯分離

當客戶預訂從 A 地到 B 地的火車票時，他既不控制火車的運行，也不選擇乘務員。在這種情況下，客戶只對結果感興趣，而不能控制實現結果的機制。服務被定義為: “任何一方可以提供給另一方的本質上是無形的，并且不會導致任何所有權的行為或表現。它的生產可能與實物產品有關，也可能與實物產品無關。”在軟件中，這被稱為“松耦合”。軟件服務是一個粗粒度的、可發現的實體，它作為單個實例存在，并與應用程序和其他服務交互。服務的概念不同于組件的概念，因為服務不定義任何結構約束，而是定義接口。

2.3 約束

盡管面向服務的軟件開發模式和基于組件的開發模式有著共同的特點，但也存在著較大的差異。它們共同的特點是軟件系統的各個部分可以單獨開發，然后再添加到系統中(進行綁定)。然而，它們綁定的方法大不相同。

基于組件的軟件假設了組件的早期綁定， 也就是說，調用單元確切地知道在運行時之前要聯系哪個組件。基于服務的開發采用了更靈活的方法，將綁定延遲到運行時，從而每次都能更改供應源。服務方法不僅允許在提供者中靈活變更，而且還適應需求質量隨時間的變化。

在基于組件的開發中，軟件組件是“從盒子里拿出來的”，然后插入到系統中，可能還添加了一些“粘合”代碼。在這種情況下，所需功能的確切來源是在運行時之前確定的。基于服務的應用程序是動態的。應用程序可以由許多服務組成。對于每個服務，可能存在許多提供者，它們提供相同的服務，但具有不同的質量特征組合。每次調用服務時，可以選擇不同的提供者來協商條款和條件，然后最終綁定服務。服務的提供者和使用者之間是松散耦合的。

在這里，服務由許多不同的服務組合而成，以提供某種結果。但是，這種組合對于服務使用者是透明的。

2.4 抽象與粒度

影響軟件變更機制的一個因素是變更的粒度。粒度是指要更改的工件規模，范圍從粗到中等到非常細的粒度。粒度是一個相對概念，只能在特定的場景中精確定義。例如，如果一個服務實現了銀行系統的所有功能，那么它可以被認為是粗粒度的。如果它只支持信貸余額檢查，那么它就被認為是細粒度的。

在20世紀90年代早期的面向對象革命之后，很明顯，面向對象技術不足以滿足現實世界軟件系統快速變化的需求。雖然面向對象的方法提供了豐富的模型來描述問題領域，但這還不足以適應不斷變化的需求。具體來說，對象過于細粒度，沒有明確區分計算和組合方面，提出的組件來封裝一組對象的計算細節。

服務應該發布在與現實世界活動或可識別的業務功能相對應的抽象級別上。服務及其方法的適當粒度級別相對較粗。服務通常支持單個獨特的業務概念或流程。它包含實現業務概念的軟件，因此可以在類似的上下文中重用它。

2.5 傳輸與通信

組件和服務之間交付機制的差異可能是個革命性概念。軟件工程主要集中于為軟件生產提供技術和管理支持，作為一種面向產品的概念。組件是面向產品的，其中軟件通過 CD 或其他媒體交付。然而，基于互聯網的計算擴散帶來了新的概念、機遇和挑戰，不僅在廣泛的一般服務規定方面，而且也在重新思考軟件交付的方法和模式方面提供了機會。將軟件作為服務交付的主要好處包括通過松散耦合提高業務敏捷性的潛力，以及隨著業務需求變化而發展的能力。

在面向服務的模型中，軟件功能作為服務交付，其中每次都需要確定功能的服務元素，協商、執行條款和條件，然后“丟棄”這使得即使在最小的功能單元級別也可以靈活地進行更改。除了技術模型的不同之外，將軟件作為服務交付還會帶來新的業務模型，這些業務模型建立在這種遠景提供的機會之上。示例包括用于計費軟件服務的業務模型、服務協商規則以及信任評估和提供。

2.6 架構

組件體系結構是控制組件之間通信的一組接口和交互規則的規范。大多數組件體系結構代表了緊耦合的情況。例如，在 CORBA (一種基于組件的體系結構)中，客戶端和服務器之間存在緊密耦合，因為兩者必須與客戶端的框架和服務器端的相應框架共享相同的接口。此外，大多數基于組件的體系結構的實現都是封閉的系統，因為它們只能處理專有技術。

面向服務的體系結構(SOA或者微服務)是一種設計軟件系統的方法，通過發布和自動發現的接口向終端用戶應用程序或其他服務提供服務。服務使用者通過代理與服務提供者解耦。面向服務的體系結構在現有 IT 環境之上添加了一個抽象層。通常，可以在組件基礎結構上添加服務層。

3.挑戰

通過組件或服務實現軟件靈活性涉及到技術和非技術挑戰。在解決方案成為商業現實之前，必須解決這些挑戰。

3.1 信任

在軟件的上下文中，正如與之相關的描述中所承諾的那樣，信任是對組件或服務將提供其功能性和非功能性義務的信心。通過檢查源代碼來測試組件并不是一種實用的解決方案。然而，信任來自未知來源的組件可以通過在使用前多次測試來部分解決。此外，對源代碼的任何更改都可能使組件契約規范失效。

在基于服務的開發中，信任問題要復雜得多，因為很難預測提供者是否符合商定的服務水平。當軟件以服務形式交付時，必須監控服務級別協議是否符合規定。對于由其他服務組成的服務，這個問題變得更加復雜。在這種情況下，服務的最終質量將取決于組成服務的服務質量。

3.2 組合管理

與動態服務組合相比，由許多組件組合的系統是相對受控的。隨著越來越多的服務提供者在大型分布式系統中公開他們的服務，人工管理和組合服務變得不可行; 這個過程必須完全自動化。與這種開放環境相關的是管理回滾、計費、許可和事務語義的問題。

3.3 適應與高級發現

組件選擇是一個設計期間的活動，隨后可能需要某種適應性。這種適應性有時被稱為膠水代碼。在基于服務的開發中，服務發現和選擇在運行時進行; 也就是說，在確定了提供的來源之后。這使得在使用前測試服務幾乎不切實際，因為服務的源以及使用條件可能在兩個連續調用之間有所不同。

在基于服務的開發中自動發現是相對于其前身基于組件的開發的最重要的進步。

使用組件構建軟件的一個主要限制是組件的指定方式。專有標準和依賴于實現的組件規范阻礙了基于組件的開發實現其促進復用的主要目標。

基于服務開發中的連接點是服務規范，而不是實現。這提供了實現透明度，并最小化了變更對軟件系統的影響。

3.4 執行效率

運行時綁定的關鍵概念是基于服務所固有的。雖然實現這樣的概念有利于靈活性，但也會導致執行開銷，特別是當每次調用功能時都要進行服務發現和匹配的時候。

4.小結

需求變更在許多軟件系統的生命周期中至關重要，特別是那些服務于高度不穩定業務領域的軟件系統。組件和服務雖然相似，但并不相同; 它們有不同的方法論和抽象，都支持一定程度的演進。方法論和抽象級別的差異使得服務成為更好的變更解決方案。

所有未來的軟件可能都是基于服務的？與其說是為了實用性，不如說是為了炒作。事實上，服務的概念適用于需求經常變化的系統，這些系統可以容忍某種低效。雖然組件是實現服務的好方法，但理想的基于組件系統并不一定產生理想的面向服務系統。因此，服務不會完全替換組件，而是補充它們。