一個對話讓你明白架構師是做什麼的？

很多人都想知道架構師是做什麼？我們看看下面的一段對話。

菜鳥  —— 剛入門的程式設計師

老鳥  —— 資深架構師

老鳥 ：菜鳥，你的目標是什麼？

菜鳥 ：我要成為一個軟體架構師。

老鳥 ：對一個年輕的工程師來說，這是一個很好的目標。那你為什麼要成為架構師呢？

菜鳥 ：我要領導一個團隊，還要做所有關於資料庫、框架和Web伺服器的重要決定。

老鳥 ：好吧，如果是這樣，你就沒必要成為一個軟體架構師了。

菜鳥 ：當然有必要了！我要成為一個能夠做所有重要決定的人。

老鳥 ：這樣很好，只是你沒有列出哪些才是重要的決定。你剛才說的那些跟重要的決定沒有什麼關係。

菜鳥 ：你說什麼？難道資料庫不重要？你知道我們在資料庫上面花了多少錢嗎？

老鳥 ：可能很多。不過資料庫仍然不是最重要的。

菜鳥 ：你怎麼能這麼說呢？資料庫可是整個系統的心臟啊！所有的資料都儲存在這裡，它們在這裡被排序，被索引，被訪問。如果沒有資料庫，整個系統就無法運作！

老鳥 ：資料庫只不過是一個IO裝置，它提供了一些有用的工具對資料進行排序、查詢，並生成報表，但這些工具都只是整個系統的附屬品。

菜鳥 ：附屬品？真是不可思議。

老鳥 ：是的，附屬品。你的系統業務邏輯或許會用到這些工具，但這些工具並非業務邏輯固有的組成部分。如果有必要，你可以隨時替換掉這些工具，但業務邏輯還是那些業務邏輯。

菜鳥 ：好吧，不過如果把這些工具替換掉，我們就要重新實現業務邏輯了。

老鳥 ：那是你的問題。

菜鳥 ：為什麼這麼說？

老鳥 ：你認為業務邏輯依賴資料庫，但實際上不是這樣的。如果你的架構足夠好，最起碼業務邏輯不應該依賴資料庫。

菜鳥 ：這太瘋狂了。我怎麼可能建立出不使用這些工具的業務邏輯？

老鳥 ：我並沒有說業務邏輯不要使用資料庫工具，我的意思是它們不應該依賴這些工具。業務邏輯不應該知道使用的是哪一種資料庫。

菜鳥 ：如果業務邏輯對資料庫一無所知，它怎麼使用這些工具呢？

老鳥 ：依賴反轉。你要讓資料庫依賴業務邏輯，而不是讓業務邏輯依賴資料庫。

菜鳥 ：你的話讓人費解。

老鳥 ：費解嗎？我講的可是軟體架構。這個就是依賴反轉原則，讓下層策略來依賴上層策略。

菜鳥 ：那就更加費解了！既然上層策略（假設你指的是業務邏輯）要呼叫下層策略（假設你指的是資料庫），那麼就應該是上層策略依賴依賴下層策略，就像呼叫者依賴被呼叫者一樣。這是眾所周知的！

老鳥 ：在執行時確實是這樣的，但在編譯時我們要把依賴反轉過來。上層策略的程式碼裡不要引用任何下層策略的程式碼。

菜鳥 ：拜託！不引用程式碼就無法呼叫它們。

老鳥 ：當然可以呼叫了。物件導向就可以做到。

菜鳥 ：物件導向對真實世界進行建模，把資料和函式組合到物件裡，把程式碼組織成直觀的結構。

老鳥 ：這是他們告訴你的嗎？

菜鳥 ：所有人都知道的，這不是很明顯的事情嗎？

老鳥 ：確實如此。不過，物件導向是可以做到不引用也能呼叫的。

菜鳥 ：好吧，那它是怎麼做到的？

老鳥 ：你應該知道，在物件導向系統裡物件會給其它物件傳送訊息的，對吧？

菜鳥 ：是的，當然。

老鳥 ：那麼你就該知道，訊息傳送者是不知道訊息接收者是什麼型別的。

菜鳥 ：這要看使用的是哪一種語言了。在Java裡，傳送者最起碼要知道接收者的基本型別。在Ruby裡，傳送者知道接收者一定會處理它所傳送的訊息。

老鳥 ：是的。不過不管是哪一種情況，傳送者都不知道接收者具體的型別。

菜鳥 ：嗯，是的。

老鳥 ：所以傳送者可以給接收者傳遞一個函式，讓接收者執行這個函式，這樣傳送者就不需要知道接收者是什麼型別了。

菜鳥 ：沒錯。我瞭解你的意思。不過傳送者仍然依賴接收者。

老鳥 ：在執行時確實是的，但在編譯時不是這樣的。傳送者的程式碼裡並沒有引用接收者的程式碼。實際上，是接收者的程式碼依賴了傳送者的程式碼。

菜鳥 ：啊！但傳送者仍然會依賴接收者的類。

老鳥 ：看來需要用程式碼來說明了，我用Java來寫些程式碼。首先是傳送者程式碼：

老鳥 ：下面是接收者程式碼：

老鳥 ：可以看到，接收者程式碼依賴了傳送者程式碼，也就是說SpecificReceiver依賴了Sender。同時可以看到，傳送者程式碼對接收者程式碼一無所知。

菜鳥 ：哈，你作弊了。你把接收者的介面放到了傳送者的類裡了。

老鳥 ：你開始明白了。

菜鳥 ：明白什麼？

老鳥 ：當然是架構原則啊。傳送者持有接收者必須實現的介面。

菜鳥 ：如果這意味著我要使用內部類，那麼……

老鳥 ：使用內部類只是方法之一，還有其它的方法。

菜鳥 ：請等一下。最開始我們討論的是資料庫，那這些跟資料庫又有什麼關係呢？

老鳥 ：讓我們來看一下其它程式碼吧。首先是一個簡單的業務邏輯

菜鳥 ：這個業務邏輯沒有做什麼事情啊。

老鳥 ：這只是個例子。在實際實現業務邏輯的時候，不會有很多類似這樣的類的。

菜鳥 ：好吧。那麼Gateway是用來做什麼的呢？

老鳥 ：它為業務邏輯提供了所有訪問資料的方法。下面是它的程式碼：

老鳥 ：要注意，這個介面是在businessRules包裡面的。

菜鳥 ：好吧。那Something這個類又是用來做什麼的呢？

老鳥 ：它代表一個簡單的業務物件。我把它放在另一個叫entities的包裡。

老鳥 ：最後需要實現BusinessRuleGateway介面，這個實現類會知道相關的資料庫細節：

老鳥 ：可以看到，業務邏輯是在執行時對資料庫進行呼叫的。而在編譯時，是database包引用了businessRules包。

菜鳥 ：好吧，我想我明白了。你用多型性隱藏了資料庫實現。不過在業務邏輯裡，仍然引用了資料庫的工具介面。

老鳥 ：不，不是這樣的。我們並沒有打算為業務邏輯提供所有的資料庫工具介面，而是業務邏輯建立了它們所需要的介面。在實現這些介面的時候，可以呼叫相應的工具。

菜鳥 ：嗯，這樣的話，如果業務邏輯需要所有的工具，那麼你必須把所有工具都放到Gateway介面裡。

老鳥 ：哈，我覺得你還是沒有明白。

菜鳥 ：不明白什麼？我覺得已經很清楚了。

老鳥 ：每個業務邏輯只定義它所需要的介面。

菜鳥 ：等等，什麼意思？

老鳥 ：這個叫作介面分離原則。每個業務邏輯只使用一部分資料庫工具，所以每個業務邏輯只定義能夠滿足需要的介面。

菜鳥 ：這樣的話，你就會有很多介面，而且有很多實現類。

老鳥 ：哈，是的。你開始明白了。

菜鳥 ：這樣子很浪費時間！我為什麼要這樣做呢？

老鳥 ：這樣做是為了讓程式碼更乾淨，並且節省時間。

菜鳥 ：算了吧，這樣只會增加更多的程式碼。

老鳥 ：相反，這其實是很重要的架構決定，這跟你之前所說的那些所謂的重要決定是不一樣的。

菜鳥 ：什麼意思？

老鳥 ：還記得你剛開始說你要成為一個軟體架構師嗎？你還想要做所有重要的決定？

菜鳥 ：是啊，我是這麼想過。

老鳥 ：你想做所有關於資料庫、Web服務和框架的決定。

菜鳥 ：是啊，而你卻說它們都不重要，還說它們其實跟重要的決定不相干。

老鳥 ：沒錯，它們確實跟重要的決定不相干。一個軟體架構師真正要做的重要決定都在資料庫、Web伺服器和框架之外。

菜鳥 ：但首先要先決定用什麼資料庫、Web伺服器或框架啊！

老鳥 ：實際上應該在開發後期才開始做這些事情——在你掌握了更多資訊之後。

老鳥 ： 當架構師草率地決定要使用一個資料庫，後來卻發現使用檔案系統效率更高 。

老鳥 ： 當架構師草率的決定使用一個Web伺服器，後來卻發現團隊需要的不過是一個socket介面 。

老鳥 ： 當架構師草率地決定使用一個框架，後來卻發現框架提供的功能是團隊不需要的，反而給團隊帶來了諸多約束 。

老鳥 ： 當架構師在掌握了足夠多的資訊後才決定該用什麼資料庫、Web伺服器或框架 。

老鳥 ： 當架構師為團隊鑑別出執行緩慢、耗費資源的IO裝置和框架，這樣他們就可以構建飛速執行的輕量級測試環境 。

老鳥 ：當架構師把注意力放在那些真正重要的事情上，並把那些不重要的事情放在一邊。

菜鳥 ：我完全不知道你在說什麼了。

老鳥 ：好吧，如果在若干年後你還沒有轉做管理，或許會明白這一切的……

對話來源網路，若有侵權，請聯絡刪除

透過上面的對話，讓我們對架構師有了個簡單的瞭解，那麼架構師在一家公司有多重要呢？架構師對一家公司、一個專案有多重要？

我們來看一看調查的資料

架構師在公司中擔當著「IT架構靈魂人物」的角色，因為他們不僅做著架構師的本職工作，還同時做程式開發，寫核心程式碼。另外，架構師依舊是技術高手，程式設計能力依然是一流的。

從圖表結果來看，架構師必須具備出色的設計能力、程式設計能力和溝通能力，在完成本職的架構工作外，還要協調好專案中人員的關係，做出合理的分工，最終完成全部工作。

最後，看下企業對Java架構師的職位描述與職位要求

從招聘資訊來看，架構師們必須是具有多年的從業經驗，有過專案開發經歷，精通多門程式語言且熟悉資料庫的大咖。所以，想以架構師為目標的讀者，就要加倍努力了！

·END·

路雖遠，行則必至

本文原發於 同名微信公眾號「程式設計師的成長之路」，回覆「1024」你懂得，給個讚唄。

微信ID：cxydczzl