|
|
Bob大叔和Simon Brown關(guān)于描述系統(tǒng)架構(gòu)時基礎(chǔ)架構(gòu)（infrastructure）所起的作用展開了討論。
在之前標題為 《尖叫的架構(gòu)（Screaming Architecture）》的文章中，Robert Martin（也就是Bob大叔）闡述了這樣的觀點：軟件產(chǎn)品的架構(gòu)應該讓所有人都很容易了解產(chǎn)品所要達到的目的，并且系統(tǒng)的架構(gòu)應該反應系統(tǒng)的用例而不是它使用的框架：
架構(gòu)不是（或者說不應該是）關(guān)于框架的內(nèi)容。架構(gòu)不應該由框架支持。框架是我們要使用的工具，而不是要符合的架構(gòu)。如果你的架構(gòu)基于框架，那么它就無法基于你的用例。
此外，好的架構(gòu)應該讓我們可以推遲那些不確定的，與框架、數(shù)據(jù)庫、web服務器等等相關(guān)的決定，Bob大叔如是說：
好的架構(gòu)讓我們直到項目的后期才需要決定使用Rails，或是Spring，或是Hibernate，或是Tomcat，或是MySql等等。好的架構(gòu)也讓我們能夠輕松地改變這些決定。好的架構(gòu)強調(diào)的是用例，并把它與周邊的關(guān)注點解耦。
Bob大叔還談到了互聯(lián)網(wǎng)，想知道那是否也應該被認為是邊緣關(guān)注點，并做出結(jié)論，網(wǎng)絡也是一種“交付機制”：
網(wǎng)絡是一種交付機制，你的應用程序架構(gòu)應該這么來對待它。你的應用程序是否通過網(wǎng)絡交付是一種細節(jié)問題，系統(tǒng)結(jié)構(gòu)不應該取決于此。實際上，你的應用程序是否通過網(wǎng)絡交付是你應該推遲考慮的事情。你的系統(tǒng)架構(gòu)應該盡可能地與如何交付無關(guān)。你應該可以把它作為控制臺應用程序、web應用程序、富客戶端應用程序、甚至是web服務應用程序來交付，而不需要讓基本的架構(gòu)過度復雜或者對其做出變更。
Bob大叔文章的結(jié)論是：你的架構(gòu)應該告訴讀者與系統(tǒng)相關(guān)的內(nèi)容，而不是你在系統(tǒng)中所使用的框架。
Simon Brown是一位軟件架構(gòu)師，他對Bob大叔關(guān)于“交付機制”的觀點發(fā)表了評論，稱之為“煩人的細節(jié)”。他同意Bob大叔所說的系統(tǒng)架構(gòu)不應該是它所使用的框架，但是他還說到，他希望“看到軟件架構(gòu)能夠落地，那就需要包括所選擇的實現(xiàn)技術(shù)。” 關(guān)于推遲決定采用何種基礎(chǔ)架構(gòu)，Brown說到：“如果我們需要做出某些關(guān)鍵的技術(shù)決定，那么肯定就需要完成，是吧？”，然后他問道：“如果我沒有，或者不能推遲做出決定，那就一定意味著我擁有很差的架構(gòu)嗎？ 我們難道不應該把推遲作為一種有意識的決定，而不是一種規(guī)則嗎？”
Bob大叔在從架構(gòu)角度考慮的時候只關(guān)注系統(tǒng)的核心領(lǐng)域知識，而Brown的方法則與之不同，他認為“交付機制”當前是很大的一塊工作，應該整合到總體架構(gòu)之中，如下圖所示：
Brown的結(jié)論是：
對我來說，架構(gòu)不僅僅是包含在“應用程序”中的內(nèi)容。結(jié)構(gòu)很重要，但是還有很多重要的內(nèi)容，像非功能性需求、實際的交付機制（技術(shù)、框架、工具、API等等）、基礎(chǔ)架構(gòu)服務（例如：記錄日志、異常處理、配置等等）、集成服務（內(nèi)部和外部的）、滿足所有環(huán)境的限制（例如：運維和支持）等等。對我來說，所有這一切都與架構(gòu)相關(guān)。
討論并沒有就此結(jié)束。Bob大叔在另一篇博文《整潔的架構(gòu)（Clean Architecture）》中對Brown的觀點作出響應，他說，不管用戶界面和數(shù)據(jù)庫部分有多大，系統(tǒng)的架構(gòu)都不應該面向這些“較大的元素”，并且“其他部分應該與之解耦”。他繼續(xù)解釋說，將核心領(lǐng)域知識與交付機制解耦非常重要，并說他不會特意地延遲和停止作出與框架相關(guān)的決定，但是架構(gòu)師應該總是可以保持這兩部分清晰地分離，即便這兩項工作同時進行：
我曾經(jīng)做出的更尖銳的關(guān)于架構(gòu)的評論是，好的架構(gòu)讓你可以延遲做出一些重要的決定，像用戶界面、框架、數(shù)據(jù)庫等等。但有些人指出，客戶不希望延遲用戶界面方面的工作。DBA也不希望延遲數(shù)據(jù)庫方面的工作。在每次迭代完成的時候，他們都希望看到整個系統(tǒng)可以正常工作，包括用戶界面、數(shù)據(jù)庫和框架。他們不希望一次迭代只處理業(yè)務規(guī)則問題。事實上，好的敏捷實踐特別要求對整體架構(gòu)做“長而薄”的切分。
當然，我完全同意這一點。然而，“長而薄”的內(nèi)容不需要同時進行。好的架構(gòu)讓你可以延遲做出重要的決定，它并不會強迫你延遲這些工作。然而，如果你可以延遲，那么就意味著你擁有更大的靈活性。例如，你可以在前面的幾個sprint中創(chuàng)建臨時的簡單用戶界面，然后再用更完備的用戶界面來替換。
Bob大叔做出結(jié)論說：“先處理這些煩人的小細節(jié)也沒什么問題，只要你能夠?qū)I(yè)務規(guī)則與它們解耦。”
Brown在對《整潔的架構(gòu)》一文的回復中做出響應：他同意Bob大叔關(guān)于解耦的觀點，但是在處理基礎(chǔ)架構(gòu)方面提出了不同的觀點：“交付機制并非是可以延遲到‘世界末日’的煩人細節(jié)”，盡管Bob大叔堅持該工作是細節(jié)問題。Brown的結(jié)論是：
在討論中，Bob大叔和Bronw并不真的是處于對立的雙方。他們都支持要清晰地分離核心領(lǐng)域知識與支持框架，但是前者更關(guān)注于領(lǐng)域知識，而后者認為還需要考慮并重視基礎(chǔ)架構(gòu)。你的方法是怎樣的呢？
英文原文：Debate: The Annoying Detail（翻譯/侯伯薇）
it知識庫：關(guān)于架構(gòu)的討論：煩人的細節(jié)，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
