清晰架構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描述了他在企業應用程式中反覆觀察到的模式。他給出了一個簡單的例子，如果每個模式，描述它是如何工作的，以及在哪裡使用它。我發現企業應用程式架構模式非常易讀並且適用於我的系統。