閱讀筆記--關於架構的討論煩人的細節

Bob大叔和Simon Brown關於描述系統架構時基礎架構（infrastructure）所起的做用展開了討論。

　　在以前標題爲 《尖叫的架構（Screaming Architecture）》的文章中，Robert Martin（也就是Bob大叔）闡述了這樣的觀點：軟件產品的架構應該讓全部人都很容易瞭解產品所要達到的目的，而且系統的架構應該反應系統的用例而不是它使用的框架：

架構不是（或者說不該該是）關於框架的內容。架構不該該由框架支持。框架是咱們要使用的工具，而不是要符合的架構。若是你的架構基於框架，那麼它就沒法基於你的用例。

　　此外，好的架構應該讓咱們能夠推遲那些不肯定的，與框架、數據庫、web服務器等等相關的決定，Bob大叔如是說：

好的架構讓咱們直到項目的後期才須要決定使用Rails，或是Spring，或是Hibernate，或是Tomcat，或是MySql等等。好的架構也讓咱們可以輕鬆地改變這些決定。好的架構強調的是用例，並把它與周邊的關注點解耦。

　　Bob大叔還談到了互聯網，想知道那是否也應該被認爲是邊緣關注點，並作出結論，網絡也是一種「交付機制」：

網絡是一種交付機制，你的應用程序架構應該這麼來對待它。你的應用程序是否經過網絡交付是一種細節問題，系統結構不該該取決於此。實際上，你的應用程序是否經過網絡交付是你應該推遲考慮的事情。你的系統架構應該儘量地與如何交付無關。你應該能夠把它做爲控制檯應用程序、web應用程序、富客戶端應用程序、甚至是web服務應用程序來交付，而不須要讓基本的架構過分複雜或者對其作出變動。

　　Bob大叔文章的結論是：你的架構應該告訴讀者與系統相關的內容，而不是你在系統中所使用的框架。

　　Simon Brown是一位軟件架構師，他對Bob大叔關於「交付機制」的觀點發表了評論，稱之爲「煩人的細節」。 他贊成Bob大叔所說的系統架構不該該是它所使用的框架，可是他還說到，他但願「看到軟件架構可以落地，那就須要包括所選擇的實現技術。」 關於推遲決定採用何種基礎架構，Brown說到：「若是咱們須要作出某些關鍵的技術決定，那麼確定就須要完成，是吧？」，而後他問道：「若是我沒有，或者 不能推遲作出決定，那就必定意味着我擁有不好的架構嗎？ 咱們難道不該該把推遲做爲一種有意識的決定，而不是一種規則嗎？」

　　Bob大叔在從架構角度考慮的時候只關注系統的核心領域知識，而Brown的方法則與之不一樣，他認爲「交付機制」當前是很大的一塊工做，應該整合到整體架構之中，以下圖所示：

 

　　Brown的結論是：

對我來講，架構不只僅是包含在「應用程序」中的內容。結構很重要，可是還有不少重要的內容，像非功能性需求、實際的交付機制（技術、框架、工具、 API等等）、基礎架構服務（例如：記錄日誌、異常處理、配置等等）、集成服務（內部和外部的）、知足全部環境的限制（例如：運維和支持）等等。對我來 說，全部這一切都與架構相關。

　　討論並無就此結束。Bob大叔在另外一篇博文《整潔的架構（Clean Architecture）》 中對Brown的觀點做出響應，他說，無論用戶界面和數據庫部分有多大，系統的架構都不該該面向這些「較大的元素」，而且「其餘部分應該與之解耦」。他繼 續解釋說，將核心領域知識與交付機制解耦很是重要，並說他不會特地地延遲和中止做出與框架相關的決定，可是架構師應該老是能夠保持這兩部分清晰地分離，即 便這兩項工做同時進行：

我曾經作出的更尖銳的關於架構的評論是，好的架構讓你能夠延遲作出一些重要的決定，像用戶界面、框架、數據庫等等。但有些人指出，客戶不但願延遲用 戶界面方面的工做。DBA也不但願延遲數據庫方面的工做。在每次迭代完成的時候，他們都但願看到整個系統能夠正常工做，包括用戶界面、數據庫和框架。他們 不但願一次迭代只處理業務規則問題。事實上，好的敏捷實踐特別要求對總體架構作「長而薄」的切分。

固然，我徹底贊成這一點。然而，「長而薄」的內容不須要同時進行。好的架構讓你能夠延遲作出重要的決定，它並不會強迫你延遲這些工做。然而，若是你 能夠延遲，那麼就意味着你擁有更大的靈活性。例如，你能夠在前面的幾個sprint中建立臨時的簡單用戶界面，而後再用更完備的用戶界面來替換。

　　Bob大叔作出結論說：「先處理這些煩人的小細節也沒什麼問題，只要你可以將業務規則與它們解耦。」

　　Brown在對《整潔的架構》一文的回覆中作出響應：他贊成Bob大叔關於解耦的觀點，可是在處理基礎架構方面提出了不一樣的觀點：「交付機制並不是是能夠延遲到‘世界末日’的煩人細節」，儘管Bob大叔堅持該工做是細節問題。Brown的結論是：

1. 將應用程序的代碼和技術解耦很不錯，並且是咱們應該盡力作到的。這樣獲得的代碼更易於作單元測試、易於替代、易於維護、易於修改等等。

2. 軟件架構是與全局相關的，而應用程序的代碼只是全局中的一部分。

3. 若是你仍然把「交付機制」這樣的重要決定推遲，而且不考慮如何解決重要的非功能性需求和約束，那麼就不得不面臨軟件項目失敗的風險。