演化式 S O A

SOA 能否以敏捷方法執行？

我不會深入探討 SOA 這個混亂的世界 (ServiceOrientedAmbiguity)，但我常常收到這個問題（以某種形式或其他形式），值得我大肆宣揚。

當我第一次接觸到敏捷軟體開發（以極限編程的形式）時，最讓我困擾的是它對軟體設計的方法。像許多人一樣，我已經習慣了軟體應該在編寫程式之前設計好的觀念，而極限編程似乎鼓勵幾乎故意擁抱設計無知。2000 年，我被要求在 第一屆敏捷/極限編程會議 上發表閉幕主旨演講，為了整理我的思緒，我最後寫了 Is Design Dead? - 一篇探討設計在敏捷世界中的命運的文章。

我仍然很為那篇文章感到自豪，而且我認為它今天仍然值得一讀 - 但對於這個 bliki 條目，我將總結一下。我談到了兩種推動軟體設計的方法：計畫式和演化式。計畫式設計在一個階段制定軟體設計，然後在之後建置（編寫程式）。在這種情況下，一旦你開始建置，就難以變更設計。演化式設計假設設計會定期變更，即使你已經完成了大量的編程。我得出的結論是，極限編程的做法提供了一種有紀律的演化式設計方法，因此比人們意識到的更實用。這種改變並沒有消除軟體設計（它並未消亡），但確實顯著改變了我們對設計的想法。

在 SOA 環境中進行規劃設計的論點在於，我們正在建構相互連結、鬆散結合的系統網路。在這種情況下，每個系統都將其服務作為 PublishedInterface 提供給整個企業。已發布的介面難以變更，因此您需要規劃設計才能正確取得這些介面，這樣您就不必變更它們。規劃設計也是對大多數組織中人們看到的混亂系統互連的反應。這種混亂是設計不良的結果，因此人們認為更好的規劃設計將防止這種情況在未來發生。

演化設計是敏捷方法的基本面向。敏捷方法的主要基礎之一是 處理、甚至歡迎變更的渴望。規劃設計假設變更很困難，因此嘗試預測變更發生在哪裡。如果變更發生在預測的界限內，那麼很容易，但如果超出這些界限，您就沒有運氣了。敏捷思維假設不可預測的變更不可避免，並嘗試以受控的方式啟用它。

因此，當我查看 SOA 或任何其他設計環境時，我提出的基本問題是「變更是否可預測？」只有在變更可預測的情況下，規劃設計方法才有效。我的感覺是，如果在單一應用程式的環境中可預測性很困難，那麼在整個企業中會更加困難。如果我們在不可預測的環境中使用規劃設計，我們會發現無論計畫有多好，它們都會受到不可預測的變更影響，導致我們目前遇到的混亂。然而，通常混亂會更糟，因為規劃設計中有大量的沉沒成本，這很容易降低 SOA 工作預期產生的商業價值，特別是在上市時間很重要的情況下。

因此，我認為我們必須咬緊牙關，找出如何在這種鬆散連接的環境中進行演化設計。畢竟，鬆散耦合的重點在於讓變更更容易。這項工作的核心是從變更的角度思考合約，並具備 消費者驅動合約 等概念。

此方向會導致類似於 Jim Webber 的 游擊隊 SOA 概念的事物。這透過產生業務價值所導向的小步驟來建置 SOA。由於產生業務價值是整個重點，因此這提供了一條可產生投資報酬率大幅提升的途徑。這肯定是一種我們的客戶所讚賞的方法。

演化設計可以擴充到 SOA 大小嗎？在我看來，我們有一個存在證明，其規模遠大於大型 SOA 專案，那就是網路本身。網路建構於非常鬆散的耦合和大量不可預測的變更之上。在許多方面，它很混亂，但這是一個有用的混亂，每天為許多人提供真正的價值。