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. 如果你仍然把“交付機制”這樣的重要決定推遲，并且不考慮如何解決重要的非功能性需求和約束，那么就不得不面臨軟件項目失敗的風險。

　　在討論中，Bob大叔和Bronw并不真的是處于對立的雙方。他們都支持要清晰地分離核心領域知識與支持框架，但是前者更關注于領域知識，而后者認為還需要考慮并重視基礎架構。你的方法是怎樣的呢？

　　英文原文：Debate: The Annoying Detail（翻譯/侯伯薇）