SOA四個原則

SOA面向服務的開發基於以下四個基本原則：

1、邊界明確
面向服務的應用程式通常由分佈在遙遠的地理位置、多個信任機構和不同執行環境中的服務組成。在複雜性和效能方面，穿越這些不同邊界的成本並不低。

面向服務的設計承認這些成本，因此對邊界穿越給予了高度重視。由於每次跨邊界通訊的成本都很高，因此面向服務基於顯式訊息傳遞模型，而不是隱式方法呼叫模型。

與分散式物件相比，面向服務模型將跨服務方法呼叫視為一種私有實現技術，而不是一種原始構造--特定互動可以作為方法呼叫來實現這一事實是一種私有實現細節，在服務邊界之外是不可見的。

雖然面向服務並不強加 RPC 風格的全網呼叫堆疊概念，但它可以支援強有力的因果關係概念。訊息通常會明確指出特定訊息屬於哪個（些）訊息鏈。這種指示對於訊息相關性和實現幾種常見的併發模型非常有用。

邊界明確的概念不僅適用於服務間通訊，也適用於開發人員之間的通訊。

即使在所有服務都部署在同一地點的情況下，每個服務的開發人員跨越地理、文化和/或組織界限也是很常見的。這些界限都會增加開發人員之間的溝通成本。

服務導向透過減少必須跨服務邊界共享的抽象概念的數量和複雜性來適應這種模式。透過儘可能縮小服務的表面積，減少了開發組織之間的互動和交流。

在面向服務的設計中，有一個主題是始終如一的，那就是簡單性和通用性不是奢侈品，而是關鍵的生存技能。

2、服務是自主的
面向服務的技術反映了現實世界，因為它並不假定存在一個無所不知或無所不能的神諭，對執行系統的所有部分都具有感知和控制能力。

服務自主性的概念體現在開發的多個方面，其中最明顯的就是部署和版本管理。

物件導向程式往往是作為一個單元部署的。儘管在 20 世紀 90 年代為實現類的獨立部署付出了巨大的努力，但事實證明，對於大多數開發組織而言，實現物件導向與元件互動所需的規範是不切實際的。再加上物件導向介面版本化的複雜性，許多組織在推出物件導向程式碼時變得極為保守。.NET框架的XCOPY部署和私有程式集功能的流行就表明了這一趨勢。

面向服務的開發不同於物件導向的開發，它假定應用程式的原子部署是例外，而不是規則。雖然單個服務幾乎總是以原子方式部署，但整個系統/應用程式的總體部署狀態很少是靜止的。單個服務的部署通常早於任何消費應用程式的開發，更不用說部署到野外了。亞馬遜公司（Amazon.com）就是這種 "先建後用 "理念的一個例子。亞馬遜的開發人員不可能知道，他們的服務會以多種方式被用於構建有趣而新穎的應用程式。

隨著時間的推移，面向服務應用程式的拓撲結構會不斷演變，有時甚至不需要管理員或開發人員的直接干預。在面向服務的系統中引入新服務的程度取決於服務互動的複雜性和以共同方式互動的服務的普遍性。面向服務鼓勵透過降低服務互動的複雜性來提高通用性。隨著特定於服務的假設滲入服務的公共介面，能合理模仿該介面並作為合理替代品的服務就會越來越少。

自主服務的概念也會影響處理故障的方式。物件被部署為在與消費應用程式相同的執行上下文中執行。面向服務的設計認為這種情況是例外，而不是常規。因此，服務認為消費應用程式可能會在沒有任何通知的情況下發生故障，而且經常是在沒有任何通知的情況下發生故障。

為了保持系統的完整性，面向服務的設計使用了多種技術來處理部分故障模式。事務、持久佇列、冗餘部署和故障轉移等技術在面向服務的系統中非常常見。

3、服務共享的是結構和契約，不是類
類：物件導向程式設計鼓勵開發人員以類的形式建立新的抽象。

類是一種方便的抽象概念，因為它們在一個命名單元中共享結構和行為。面向服務的開發沒有這樣的結構。相反，服務的互動完全基於模式（結構）和契約（行為）。

每個服務都會公佈一個合約：

• 該合約描述了它可以傳送和/或接收的資訊結構，
• 以及對這些資訊的一定程度的排序約束。

服務本身不涉及型別或類，而只涉及服務支援的機器可讀和可驗證描述。

• 考慮到面向服務的應用程式的開發和部署方式本身具有分散式性質，因此強調機器可驗證性和驗證非常重要。
• 與傳統的類庫不同，服務必須非常謹慎地驗證每條資訊中的輸入資料。
• 基於機器驗證相容模式和合約的架構為開發人員和基礎架構提供了保護單個服務和整個應用程式完整性所需的提示。

由於特定服務的結構與合約在廣闊的空間和時間範圍內都是可見的，因此服務導向要求結構與合約式在一段時間內保持穩定。

• 在一般情況下，不可能將結構與合約的變更傳播給遇到過服務的所有各方。
• 因此，與傳統的物件導向介面相比，面向服務設計中使用的結構與合約往往具有更大的靈活性。
• 服務通常會使用 XML 元素萬用字元（如 xsd:any）和可選的 SOAP 標頭塊等功能，以不破壞已部署程式碼的方式發展服務。

4、服務相容性是根據策略確定的
物件導向的設計常常混淆結構相容性和語義相容性。面向服務分別處理這兩個方面。結構相容性以結構與合約為基礎，可以透過機器技術（如資料包嗅探、驗證防火牆）來驗證（如果不是強制執行的話）。語義相容性則以策略形式明確說明能力和要求。

每項服務都以機器可讀策略表示式的形式公佈其能力和要求。

• 策略表示式指出了哪些條件和保證（稱為斷言）必須成立才能使服務正常執行。
• 策略斷言由一個穩定且全域性唯一的名稱標識，無論該斷言應用於哪項服務，其含義在時間和空間上都是一致的。
• 策略斷言還可能帶有引數，用於限定斷言的確切解釋。
• 單個策略斷言對整個系統來說是不透明的，這就使得實現者可以應用簡單的命題邏輯來確定服務相容性。

banq注：
本文發表於2004年，後來2008年DDD概念更加細化：

• 服務=後來發展為微服務，DDD中限定上下文BC，服務代表不同上下文，分散式環境、客戶端與服務端（後來被RESTful分擔）
• 物件導向=DDD中聚合根物件