大多數內部 REST API 都是一次性的 API，專門為單一整合點而建置。在本文中，我將探討非公開 API 的限制和彈性，以及從跨多個團隊進行大規模 RESTful 整合中學到的教訓。

一個模型（由 Leonard Richardson 開發），將 REST 方法的主要元素分解為三個步驟。這些步驟引入了資源、http 動詞和超媒體控制。

良好的技術設計決策非常依賴於背景。經常為共同目標而合作的團隊能夠定期溝通並快速協商變更。這些團隊展現出強大的力量，並能做出利用這種強大力量的技術和設計決策。當我們在較大的組織中縮小範圍時，在獨立工作且較少頻繁合作的團隊和部門之間會存在越來越薄弱的力量。認識到這些強大力量和薄弱力量的差異，讓我們能夠做出更好的決策，並為每個層級提供更好的指導，讓團隊更有權限，並能更快速地行動。

商業整合工具現已問世數十年，但鮮少有概括性的架構原則說明何時以及如何使用這些工具。在本文中，我主張「購買」決策機制導致我們誇大了此類工具的價值主張，通常會導致強制使用特定整合工具，而非通用語言。我主張此類工具在視整合為主要連接系統的世界中蓬勃發展，但數位組織已重新構想整合，主要在於將乾淨的介面放在數位功能之前，強調功能而非系統。最後，我列出現代整合觀點背後的一些關鍵原則，並主張使用通用語言可以最佳管理這些原則，重新調整商業整合工具的主要價值主張，以簡化戰術實作考量。

我的同事 Jim Webber 以輕量化和以業務為導向的方式處理企業整合而建立了相當的聲譽。他也以健談且幽默風趣的演說家而聞名。因此，我既緊張又興奮地與他在 QCon 2008 年的基調演講中同台。他準備了一個非常有趣的簡報，其中穿插了一些嚴肅的重點。然後，我們就開始了，也許是受到演講前的品脫啤酒幫助。我們談到了企業整合的歷史、自以為強大但實際上只是肥胖的系統的成長、敏捷思考的角色、網路的影響（包括 Jim 關於網路發明原因的獨特理論），以及這如何導致游擊隊 SOA。

本文探討服務供應商和消費者社群演變中的一些挑戰。它描述服務供應商變更合約部分內容（特別是文件結構）時出現的一些耦合問題，並找出兩個廣為人知的策略，分別是新增結構擴充點和執行接收訊息的「剛好足夠」驗證，以減輕此類問題。這兩個策略都能保護消費者免於供應商合約變更的影響，但都沒有讓供應商深入了解其使用方式，以及在演變過程中必須維持的義務。本文根據其中一個減輕策略（「剛好足夠」驗證策略）的基於斷言的語言，描述「消費者驅動合約」模式，讓供應商深入了解其消費者義務，並將服務演變集中在提供消費者要求的主要業務功能上。

近年來，關於無架構資料優點的討論越來越多。無架構是對NoSQL 資料庫感興趣的主要原因之一。但無架構涉及許多細微差別，無論是資料庫或記憶體內資料結構都是如此。這些細微差別存在於無架構的意義，以及使用無架構方法的優缺點中。

我使用「應用程式資料庫」一詞來表示由單一應用程式控制和存取的資料庫（與整合資料庫相反）。由於只有單一應用程式存取資料庫，因此可以特別定義資料庫以滿足該應用程式的需求。這會產生一個更具體的結構，通常比整合資料庫更容易理解，而且通常也較不複雜。

有界脈絡是領域驅動設計中的核心模式。這是 DDD 策略設計區段的重點，這個區段完全在處理大型模型和團隊。DDD 透過將大型模型分為不同的有界脈絡，並明確說明它們的交互關係，來處理大型模型。

當我談論資料庫以及它們與應用程式之間的關係時，我發現區分兩種資料庫樣式很有用：應用程式資料庫和整合資料庫。兩者的差別在於資料庫是否受單一應用程式邊界控制和封裝。

在本世紀初，我撰寫了我的書企業應用程式架構模式。在撰寫這本書時，我遇到的問題之一是如何為它命名，或者更確切地說，如何稱呼我撰寫的軟體系統類型。我始終意識到，我在軟體開發方面的經驗一直專注於一種特定的軟體形式，例如醫療保健記錄、外匯交易、薪資和租賃會計。這些與印表機、遊戲、飛航控制軟體或電話交換機內的嵌入式軟體非常不同。我需要一個名稱來描述這些系統類型，並決定使用「企業應用程式」這個術語。

最近我在 Amazon 上看到幾篇關於P of EAA的負面評論，因為書中沒有提到企業架構。當然，這有充分的理由，因為這本書探討的是企業應用程式架構，也就是如何設計企業應用程式。企業架構是一個不同的主題，探討如何將企業中的多個應用程式組織成一個有意義的整體。

SOA 可以用敏捷方法來完成嗎？

SOA 狂熱者宣傳的新世界服務功能之一是登錄的概念。這通常以自動化系統的形式描述，允許系統自動在登錄中查詢有用的服務，並自行繫結和使用這些服務。

電腦偶爾看起來很聰明，但我並不特別認同這個想法。雖然自動化服務查詢可能會有奇怪的邊緣案例，但我認為在 20 次中會有 22 次是由人類程式設計師在進行查詢。

整合資料庫是一個資料庫，可作為多個應用程式的資料儲存，因此整合了這些應用程式中的資料（與 應用程式資料庫 相反）。

探索任何大型企業，你通常會發現某種專注於企業級概念建模的團隊。最常見的是資料管理團隊，偶爾他們可能會參與定義企業級服務。它們之所以是企業級的，是因為它們專注於整合多個應用程式，而不是專注於單一應用程式的努力。

對於為服務導向架構建立服務的任何人來說，這是一個重要的想法。當你建立服務時，還要建立一個 服務 Stub，你的客戶可以使用它來進行測試。這樣的 Stub 應該針對一組固定的請求提供罐頭回應，模擬錯誤狀況，並且可以在客戶端的機器上執行。你需要確保 Stub 正確地模擬真實系統行為。透過為你的客戶提供 Stub，你可以讓你的客戶更容易使用你的服務；這當然表示你的服務更有可能被使用。

讓我們想像一個 SOA 快樂的美好世界，在那裡企業的運算需求被分割成許多小型應用程式，這些應用程式彼此提供服務以允許有效協作。在一個美好的早晨，一個消費者服務需要從供應商服務中獲取一些資訊。關鍵在於，儘管供應商服務具有取得此資訊所需的資料和處理邏輯，但它尚未透過服務介面公開該資訊。供應商有一個潛在的服務，但它實際上還不存在。

每當 Thoughtworks 魯莽地讓我出現在客戶面前時，我一定會被問到一個問題：「你對 SOA（服務導向架構）有什麼看法？」這是一個幾乎不可能回答的問題，因為 SOA 對不同的人來說有不同的意義。

使用網路服務的優點之一是它可以幫助你解耦系統的各個部分。人們可以在一定程度的分離下處理不同的程式碼庫。儘管你獲得了一些解耦，但你無法完全消除耦合，因為服務仍然必須透過其介面彼此通訊。可悲的是，許多團隊讓這種耦合變得比它應該的更糟。