本文為《架構漫談》系列第一篇。本文將會從：”什么是架構”，“架構能解決什么問題”，“架構和框架的區別”三個點來著重討論,本文系個人觀點,如有不正確的地方,歡迎指正討論。

?

什么是架構？

　　每當我們開發新的項目的時候都會新建一個解決方案,然后在解決方案中搭建N個項目。每個項目之間通過“引用”達到交互的功能,這個過程就可以稱之架構,而架構最終的產物則是軟件產品。不同的程序員在搭建架構的時候分兩種情況：熟悉業務,根據業務進行架構、不熟悉業務,根據自己的理解進行架構。這兩種情況在軟件工程行業中有兩個名詞進行描述，分別是“隱式架構”和“顯式架構”。

　　舉個例子,讓一個經驗豐富的程序員去開發一個Blog系統,經驗豐富的程序員的腦中就會有一個Blog系統的大體架構,比如功能等等。。反之,如果讓一個新手去開發一個Blog系統,那么他可能因為不了解需求、功能等問題需要耽擱很久，所以這時候就需要我們把架構給展現出來,通過草圖或UML告訴程序員有哪些功能模塊,以及它們之間的關聯等等來幫助程序員開發。

　　架構不能脫其需實現的系統而存在。在進行軟件架構之前,我們需要理解系統是如何和外部環境發生關系的以及如何嵌入到外部環境中的。架構是一個系統最為核心的部分,是構造系統過程中的支柱。在進行系統架構前,我們往往需要了解很多方面的東西。例如：分析需求、設計系統、根據其技術語言的本身來確保架構的可行性。

　　完美的設計不是包羅萬向無所不在,而是完整自洽不可精簡。

?

架構能解決什么問題

　　這個問題可以用一句話來回答：架構是為了解決系統的復雜性,也同時保證了系統的可維護性。

　　一旦進入開發階段,在架構中我們所定義的一些功能則不能被輕易改變。這里僅僅是指不會輕易改變而不是不能改變。而一些功能可以會隨著的業務的變更發生更改，但有了架構之后,我們改起來非常容易。舉個例子,某公司需要開發一個金融系統,在開發系統前沒有專業的人員進行架構,招了一些程序員分完工就開始寫功能。這些程序員在寫某一個功能點時根本不會去考慮這個功能別人有沒有寫過,直接就開始寫,殊不知他們寫的這個功能已經有幾個人都寫了。而這時,BOSS說某個功能需要修改,那么這些重復的"輪子"都要跟著修改,如果某位程序員忘記了修改則會導致系統的崩潰。再或者,當時寫這個金融系統的程序員如果全部辭職,公司在招人來繼續開發這個項目,由于沒有整體的架構圖可能會導致這個項目無法繼續維護下去,最終可能導致項目失敗。

　　

架構和框架的區別

　　很多人都會把框架和架構混為一談,其實不然。框架是軟件,而架構不是軟件。

　　框架是一種特殊的軟件，它并不能提供完整無缺的解決方案，而是為你構建解決方案提供良好的基礎。框架是半成品。典型地，框架是系統或子系統的半成品；框架中的服務尅被最終應用系統直接調用，而框架中的擴展點是供應用開發人員定制的“可變化點”。

? ? ? 架構不是軟件，而是關于軟件如何設計的重要策略。軟件架構決策設計到如何將軟件系統分解成不同的部分、各部分之間的靜態結構關系和動態交互關系等。經過完整的開發過程之后，這些架構決策將體現在最終開發出的軟件系統中；當然，引入軟件架構之后，整個開發過程變成了“分兩步走”，而架構決策往往會體現在框架之中。或許，人們常把架構和框架混為一談的原因就在于此吧！我們不能指著某些代碼，說這就是軟件架構，因為軟件架構是比具體代碼高一個抽象層次的概念。架構勢必被代碼所體現和遵循，但任何一段具體的代碼都代表不了架構。

? ? ? 框架技術和架構技術的出現，都是為了解決軟件系統日益復雜所帶來的困難而采取“分而治之”思維的結果-----先大局后局部，就出現了架構；先通用后專用，就出現了框架。下圖很好地揭示了這一點。架構是問題的抽象解決方案，它關注大局而忽略細節；而框架是通用半成品，還必須根據具體需求進一步定制開發才能變成應用系統。

轉載于:https://www.cnblogs.com/dazhuangtage/p/5645302.html

總結

以上是生活随笔為你收集整理的架构漫谈：我心中的架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。