為什么我不推薦鮑勃叔叔的清晰架構這本書?

18-12-05 banq
                   

清晰架構Clean Architecture,又稱干凈架構、清晰架構、整潔架構、清潔架構,是著名軟件工程大師Robert C Martin提出的一種架構整潔之道。以下是原文大意,原文點擊標題進入。

清晰架構無法滿足我在許多方面的期望。盡管馬丁先生對其表現出了非常的熱情,但清晰架構的組織性很差,缺乏實例,并且對現有系統的使用保持沉默。作者錯過了一個重要的機會來教我們何時以及如何將這些課程應用到我們自己的系統中。

清晰架構是一本組織不良的書

這本書閱讀到核心內容需要先經歷很長時間,關于設計范式(結構化,面向對象和函數)的章節似乎特別不合適且不必要。

關于SOLID原則的章節很好。我很高興看到這些原則被打破并解釋得很好。我發現考慮它們對系統架構的適用性很有意思。但鮑勃叔叔提出了像硬規則這樣的SOLID原則,這種原則讓我會產生誤解。事實上,我很確定違反SOLID原則的系統將是一個巨大的混亂系統。

但是,第137頁的這一段很重要:

架構的主要目的是支持系統的生命周期。良好的架構使系統易于理解,易于開發,易于維護和易于部署。最終目標是最小化系統的壽命成本并最大化程序員的生產力。

這是一個很好的見解,鮑勃叔叔為什么不把它放在第一章?

沒有足夠的例子

本書幾乎沒有任何例子。第33章包含一個討論視頻銷售電子商務應用程序的示例。我一直在想如何將這些概念應用到我自己的系統中。

附錄講述了鮑勃叔叔如何提出SOLID原則和清晰架構規則的故事。它載有過去項目的例子。我認為這是本書最有趣的部分。

本書沒有提到改進現有系統的架構

大多數開發人員將大部分時間花在現有系統上。因此,我希望清晰架構這本書能夠提供有關改進現有系統的建議。但是這本書在這個問題上顯而易見地保持沉默。

如何創建一個干凈、清晰的架構?

在本書的前半部分,您將了解到通過遵循SOLID原則創建一個清晰架構,將系統分解為系統邊界內的組件。在本書的最后,在第228頁:

此示例旨在表明架構邊界存在于任何地方。作為架構師,我們必須小心地識別何時需要它們。我們還必須意識到,這些邊界在完全實施時是昂貴的。

與此同時,我們必須認識到,當忽略這些邊界時,即使在全面的測試套件和重構規則的存在下,它們在以后添加也非常昂貴。

那么我們架構師做些什么?答案是不滿意的。一方面,一些非常聰明的人多年來告訴我們,我們不應該提前預測哪些需要抽象。這是YAGNI的理念:“你不需要它。”?這條信息有智慧,因為過度工程往往比工程設計更糟糕。但是,另一方面,當您發現你確實需要一個之前不存在的架構邊界時,添加這樣的邊界的成本和風險可能非常高。

所以你必須看到未來。你必須聰明地猜測。您必須權衡成本并確定架構邊界所在的位置,哪些應該完全實現,哪些應該部分實現,哪些應該被忽略。

因此,他說(本書的一半以上),我們應該決定將邊界這個概念放在我們的系統中。這種邊界可能無處不在。令人困惑,對吧?

(banq注:理解了DDD就知道,這種邊界是一種上下文邊界,而從哲學上看,這是一種邏輯邊界,世界這個詞語本身就包含邊界,邊界是人的主觀和客觀之間的符號,這是一種三元論世界觀,二元論和一元論世界觀的人很難理解。)

這本書遺失了什么

因此,如果軟件架構的最終目標是最小化系統的生命周期成本,那么架構書是否應該幫助架構師做出這些決策呢?

這本書給我留下了許多未解答的問題。各種選擇的經濟學討論在哪里?如何為我的系統找到最佳架構?研究在哪里?

如何確定水平分層或垂直切片或其他什么方法可以最大限度地降低系統的生命周期成本?或者,如果我沒有明確定義的架構分層,我如何決定哪種分層策略可以最小化我的生命周期成本?

我還有更多問題。如果你有足夠的時間來改進現有系統的架構,你應該把你的努力放在哪里?將數據庫與業務邏輯分開是不是總是一個好主意?(banq注:實際系統中大部分是使用數據庫實現業務邏輯,因此數據庫Oracle等和業務邏輯是混合在一起,而DDD則是讓你明白這點,但是做到分離是一種革命性的工作,幾代人努力吧。)你應該遵循哪些建議?哪些建議取決于系統?

使Clean Architecture更有價值的細節

Code Complete中,Steve McConnell討論了可靠性,可靠性,正確性,可維護性,可讀性等不同非功能性需求之間的權衡。他解釋了一些需求如何一起變動而與另一些需求發生沖突(banq注:需求概念之間的邏輯矛盾,實現邏輯一致性梳理是必要的,不能等到軟件實現以后才發現,這種代價是昂貴的)。對于本書中討論的架構決策,我本來希望看到類似的內容。

在清晰架構中,項目規模,團隊規模,項目失敗的后果,預期的代碼生存期以及其他重要因素都未被強調為架構的驅動因素。

這本書的真正含義

打個形象的比喻說明這本書含義:

想象一下,您正在為消費市場構建臺式計算機(例如辦公室計算機)。你可以選擇硬件,然后你將為整個事情編寫一套系統(包含硬件,操作系統,驅動程序,應用程序,一切)。

你會寫一個巨石單體系統嗎?你會寫一個巨大一整塊程序嗎?比如使用電子表格編碼,它能知道如何為你的計算機選擇磁盤類型嗎?您能想象任何地方添加“if”語句,以便在您擁有SATA驅動器時執行一項操作嗎?如果您有SCSI驅動器則執行另一項操作嗎?

那將是一場噩夢,對吧?那么解決方案是什么?架構!您的電子表格代碼不應該知道您正在使用哪種磁盤。

那么什么是計算機中的邊界?

如果看看你的電腦,那你就會發現:鼠標中有嵌入式軟件,可與您的操作系統進行通信。然而,細節隱藏在您的應用程序中。您的電子表格接受標準化輸入,而不知道或不關心您使用的是哪種鼠標或磁盤。然后當有人發明像觸摸板這樣的新輸入設備時,它會自動與電子表格配合使用。

這只是您計算機的一個邊界。你可能會想出數百個。您可以指派不同的團隊來處理系統的不同部分。您可以為不同組件交互的各種方式創建或采用不同的規范。

你可能在這一點上說'呃'。很明顯,每次硬件更改時,您都不希望更改和重新編譯電子表格。維護將是一場噩夢。

邊界是你的朋友(如果你正確使用它們)

很容易看到硬件邊界。但是,硬件邊界的同樣邏輯也適用于軟件邊界。軟件邊界很難看到。

因此,您可以從屏幕上顯示電子表格的操作開始。可能想將其保存到磁盤,將其保存為PDF,或將其另存為CSV或打印。因此,電子表格程序中的一個邊界可能是擁有代表每個電子表格的內部數據結構。然后將該結構傳遞給不同的代碼,以所需的格式顯示,保存或打印它。

如果您使數據結構完全解耦它的顯示,保存或打印方式,那么您可以在未來的情況下添加“保存到XML”等新功能,這就無需瀏覽與電子表格數據結構相關的所有代碼。如果該電子表格數據結構是數百萬行代碼,您可以想象添加新功能會有多容易!

這就是鮑勃叔叔試圖在本書中告訴我們的。您可以使用SOLID原則在系統中創建邊界,隱藏實施細節,降低復雜性,并幫助您降低系統的總生命周期成本。

更好的軟件架構書:

在許多方面,Martin Fowler?的企業應用程序架構模式遠遠優于Clean Architecture。Fowler描述了他在企業應用程序中反復觀察到的模式。他給出了一個簡單的例子,如果每個模式,描述它是如何工作的,以及在哪里使用它。我發現企業應用程序架構模式非常易讀并且適用于我的系統。

?

                   

2
qiu768
2018-12-19 17:36

請教下banq,感覺martin fowler的那本架構模式里面的內容都有點偏舊了。除了那本架構模式請問還有沒有其他講解架構方面的書籍是你覺得不錯的,能否推薦一兩本,不勝感激。

banq
2018-12-19 18:31

>感覺martin fowler的那本架構模式里面的內容都有點偏舊了

架構確實不斷在發展,MF的業務分析模式還是不錯都在DDD中發揚光大,架構方面還真的是這本又稱為清潔架構的書了,其實核心就是業務邏輯為王,其他技術只能依賴業務模型,而不能倒過來,甚至業務邏輯不能放在Oracle等數據庫表中,這些方式其實在DDD+領域事件等方式已經實現了,包括發言的這個軟件JiveJdon就是基于清潔架構實現的,十年前的作品了,雖然前端陳舊,但是業務模型一直是根據DDD設計,保持長青。其他如果還有什么書籍,可持續關注我的動態更新,暫時沒有想起來哈,抱歉。

sinaID80865
2019-08-20 10:36

不錯,學習到了。

一级黄色录像影片 夫妻性生活影片 免费在线观看 一级a做爰片