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