基礎的流動性 - 實際影響

Question

一個由洋蔥架構所提供的主要優點是換出「基礎設施」的元素，如「數據訪問，I/O和網絡服務」（http://jeffreypalermo.com/blog/the-onion-architecture-part-3/）的能力。

傑夫說，在他的崗位從2008年說，「行業已經修改的數據訪問技術每三年至少」。

有沒有人有一個相當大的項目的例子，其中使用洋蔥結構和換出關鍵的基礎設施要素隨後被承擔？

我有興趣瞭解：

• 如何常見的是這種情況下，有什麼看法？

我的直覺告訴我，雖然「數據訪問技術」可能會每三年修改一次，但運行解決方案的實際基礎架構的變化（可以實現此益處）可能會少得多？

• 條件是該解決方案最初運行的條件是什麼？
• 是什麼導致了底層基礎設施的變化？
• 是否有教訓關於這種方式改變基礎設施的實際影響，這可以使我們能夠改進洋蔥架構的原實現學到什麼？

我很想知道除了更換基礎設施組件和實現相同的接口之外是否還有意外的更改。例如，新基礎設施是否需要將新參數傳遞給先前定義的方法，例如SaveOrder（int ID） - > SaveOrder（int ID，bool AllowSiblings，bool SiblingCreated）從關係移動到NoSQL DB模型時。

• 與傳統的耦合方法相比，實施此架構+返工遷移到新基礎架構是否顯着降低了所需的總體工作量？

• 開發者是否發現耦合的，硬引用的代碼比鬆散耦合的，間接引用的代碼更易於編寫和調試，但基礎架構更改的最終收益是否值得呢？

Answer 1

嘛，恕我直言，這樣的建築風格（Hexagoanl，港口&適配器，洋蔥...）的主要目的是，它可以讓你專注於自己的領域，你將如何，而不是實現重點首先是UI的價值，框架或存儲問題。它允許你推遲這樣的決定。

正如傑弗裏所說，換出「基礎設施」元素的能力是這種架構風格的一個很好的副作用。儘管你不會每隔6個月從一個關係數據庫切換到另一個關係關係數據庫，但是我們知道盡可能無痛苦地完成這個任務是非常令人放心的。

不是想着定期更改您的存儲機制或如你所說的「關鍵基礎設施部件的換出」相反，想想第三方服務，你會堵塞你的系統。那些渴望定期改變的人;你也可以從一個提供者切換到另一個提供者。這是我們習慣於更經常地面對的一種更常見的情況。在這種特殊情況下，域行爲不會改變，接口將保持不變，您不必將單行代碼更改爲核心域層。只有在基礎架構層中的某個實現可能需要更改。這是來自這種架構的另一個值得注意的好處！

請閱讀this nice Uncle Bob article關於清潔架構，他解釋了爲什麼延遲關鍵基礎架構決策的能力非常酷！

---編輯---

你能提供的，你必須換出第三方服務的例子嗎？

我們有很多例子，我們從一個提供者切換到另一個提供者（從支付提供者到活動提供者或任何提供者）。業務保持不變，領域行爲仍然相同。更改提供商不應對您的業務產生任何影響。您不必改變您的業務運作方式，價值的確切位置，僅僅因爲您從一個供應商變爲另一個供應商，這是沒有意義的。在獨立的核心層中隔離您的域行爲，不依賴於任何第三方庫，框架或提供者服務，絕對有助於您應對更改。

我有這樣的感覺，你試圖說服自己是否要去洋蔥。你可能只是在考慮遷移到新的基礎設施相關的東西（數據庫，第三方的東西.​​.....）。改爲關注你的域名。問問你自己，如果你的域名足夠複雜，需要這樣的架構風格。不要使用火箭筒殺死蒼蠅。由於Simon Brown說：「原則是好的，但要確保它們是現實的，沒有負面影響」！

如果您的應用程序很小，沒有複雜的業務領域，可以選擇經典的n層架構，沒關係;不要爲了它而改變事物，也不要僅僅因爲任何流行語。但是請記住，在Onion體系結構中，沒有依賴關係的孤立核心業務層可能非常容易進行單元測試！

現在您還有其他問題：

難道這種架構+實施返工遷移到新的基礎設施顯著減少所需的總工作量，如果相對於傳統，耦合方法？

這要看！ :-)在緊密耦合的應用程序中，只要有一個新的基礎架構元素需要遷移，毫無疑問，您肯定必須修改每個層（包括業務層）中的代碼。但是，如果這個應用程序很小，很簡單，組織良好，並且有一個下降測試代碼覆蓋率，這應該不是什麼大問題。現在，如果它相當大，並且業務領域更加複雜，那麼將這一層分離成完全獨立的層並且完全不存在依賴關係可能是一個好主意，這樣可以確保基礎架構更改不會導致任何業務迴歸。

開發人員發現耦合的，硬引用的代碼比鬆散耦合的，間接引用的代碼更容易編寫和調試，但基礎架構更改的最終收益是否值得呢？

好吧，問問你的隊友！他們是否習慣與國際奧委會合作？請記住，架構設計和選擇必須是團隊決策。這必須是整個團隊共享的東西。