《架構漫談》閱讀筆記九

從架構師的角度去看如何去寫代碼：從剛開始重寫代碼，推翻原有架構，從新設計等等說法，來講明架構的進化。這實際上就是當初爲了完成任務，沒有充分思考所帶來的後果。這也並非架構進化的事情，而是我的對問題領域的逐漸深刻理解的過程。以上只是針對單一的Service部署單元的分析，擴展開去，對於其餘的部署單元也是相似的。每一個單元的下一級均可以認爲是Repository，每一個單元的上一級均可以認爲是User。這些實踐在我本身的項目中都有用到，很是的有效，迭代的速度很是的快。不少人擔憂Business Model建很差，其實不要緊，剛開始能夠粗糙一點，後續能夠慢慢的完善。這個架構已經隔離好了每一個部分的變化對其餘部分的影響，變化成本都在可控的範圍以內。

當咱們有了好的架構，那就須要考慮如何將架構落地，而這個時候，代碼就顯得無比重要了！千萬不要讓代碼成爲架構擴展的瓶頸。

軟件架構實際上包括了：代碼架構，以及承載代碼運行的硬件部署架構。實際上，硬件部署架構最終仍是由代碼的架構來決定。由於代碼架構不合理，是沒法把一個運行單元分拆出多個來的，那麼硬件架構能分拆的就很是的有限，整個系統最終很難長的更大。

因此咱們常常會據說，重寫代碼，推翻原有架構，從新設計等等說法，來講明架構的進化。這實際上就是當初爲了完成任務，沒有充分思考所帶來的後果。這也並非架構進化的事情，而是我的對問題領域的逐漸深刻理解的過程。因此有必要再討論一下，代碼的架構應該是怎樣的。

架構師和技術

不少人會問，特別是作軟件行業的，架構師是否是須要學習技術，甚至是學習語言？ 若是一個架構師還有這個困擾—就如問這個問題的人，說明目前還不具有作架構師的能力，或者說還不具有對本身領域–哪怕是技術領域–的自信，更別談業務領域了。

由於技術和語言，都是用來識別和解決所服務的主體的權責，保護並提高所服務的主體的權利的。特別對於軟件領域來講，必須明白軟件自己是怎麼回事，解決什麼問題，還要解決軟件所服務的對象的領域自己是怎麼回事，解決什麼問題，這就要求更高了。語言和技術應該是隨手拈來纔對，對於架構師這些都是工具。學習技術和語言，若是明白了這些技術和語言要解決的是誰的問題，什麼問題，學起來是很是快，很是容易的。

一樣，採用哪一個技術或者語言，只要某個技術或語言所解決的問題的主體，以及所解決的問題，和本身所面對的問題的主體和這個主體要解決的問題，這二者是匹配的，那麼這個方案是成本是最低的，所採用的技術或者語言就是靠譜的。沒有趁手的工具或語言的狀況下，本身設計一個也不難，由於很清楚本身要什麼。要不要本身作，無非是一個成本問題，也就是利益問題。而且從這個思路下去，選擇的工具和語言確定都是最簡單的，成本是最低的。由於架構畢竟解決的仍是人的利益問題，成本越低越好，這個成本固然是長期整體成本，不是眼前的短時間成本。