前一篇說了原理，軟體架構本質上是繪製一幅複雜素描所打的草稿，我還說，如果你罩得住，可以不需要這個草稿。

但這只是“理論上”，我們寫軟體，基本上不是在寫只有幾千行的程式碼的小程式，而是寫數千萬行的大型程式。《道德經》說得好，大曰逝，逝曰遠，遠曰反。一件事情變大以後，原來近在眼前的事情看到的策略，方法，都會反過來。我舉簡單程式的例子，是反向化簡模型，所謂“執古之道以御今之有。能知古始， 是謂道紀”，是讓讀者從原始的推演中重新理解我們面對複雜問題時的應該把握的判斷模型，是給你講“道紀”。所以，看我的文章，你不要看我的結論，你要看我的Pattern，我的結論在不同的情形下是不斷會變的，我要給你講的是Pattern，不是要給你講結論。

我們很多工程師在沒有經驗的時候，想架構問題都會基於邏輯來想。但如果沒有經驗，這常常是錯誤的。 我前面舉了個例子，我剛入行的時候（其實現在很多人還有這個誤區），當我們發現需求做錯了，實現和設計不一致的時候，我們都會做出一個判斷：這是需求文件寫得不夠嚴謹，設計文件不接地氣。這個判斷方向基本上是緣木求魚。我是認為幹了好幾年，還是抱這種心思的工程師，基本上架構設計水平也就到此為止了。因為你始終無法堅持要“守弱”這個基本原則，你不相信事實，而去相信你的理想了。你寫了幾年的程式，一直以來需求文件都不夠嚴謹，設計文件一直不接地氣，甚至從來沒有改進過，你還不斷相信，你有一天能寫出“嚴謹”的文件？你完全被你的個人想象矇蔽了眼睛，從來沒有好好看過這個世界啊。

這個問題到底是什麼？是工作量啊。整個軟體，其實就是一組邏輯，每行軟體程式碼，都是針對不同角度的的邏輯判斷。而我們在控制這個軟體的所有邏輯被建成以前。我們的邏輯量永遠都是不足的啊，如果足了，你根本就不需要設計（包括架構設計）了，你已經擁有你的程式碼了。所以，構架設計是要在邏輯量不足（邏輯不嚴謹）的情況下對未來進行預判和控制。而你指望建設好所有的邏輯來解決這個問題？這麼明顯的邏輯死迴圈你都沒有注意到嗎？那你已經忘掉架構設計本來的工作是什麼了。

就好比一個領導者，他的工作本應是告訴大家想什麼方向走，保證團隊能走目的地。你的工作照理說是研究情報，確認對整個團隊影響最大的情報，在模凌兩可的情況下強行選定方向等等。但這些事情他不去幹，而跑去給團隊做飯，去充當斥侯探路之類的，看起來很“親民”，和團隊打成一片，但他自己的本職工作呢？

領導者的本職工作是隱形的，是“無名”的，做好了飯，拿到了情報，這些都是有形的，選好方向，讓飯做好了，讓情報發揮作用，這些行動，並不直接可見，領導者想拿“名”，團隊就會失去領導，團隊就會失敗，團隊失敗了，領導者也就無所謂名了，整個團隊都會被歷史淘汰。這就是為什麼聖人無私才能成其私，放棄掉你的名，你才讓整個團隊擁有名，擁有整個團隊的名，你才能有你的名。這就是作為領導者的大格局。

而架構師，就是設計團隊的設計領導者。

寫到這裡，我看我還是得把這個連結放出來：《道德經》講了什麼？為什麼它廣受推崇？ - in nek 的回答 。那麼辛苦建那個邏輯空間，就是為了描述構架設計的時候，有很多基礎概念可以用，否則，後面要描述那些具體技巧的時候，簡直不知道應該怎麼描述了。

所以，要接著看下去，讀者還是看看那個連結吧。我後面會原來越多使用裡面的概念的。