今天主要談談這么幾個問題?
第一、架構設計的目的是什么？
第二、架構設計的常見誤區？
1.不做架構設計的系統難道就跑不起來嗎?
2.設計良好的架構能促進業務發展嗎?
第三、不是每個系統都需要做架構設計?
第四、為了高性能、高可用、可擴展，所以要做架構設計?
這四個問題摘自李運華先生在極客時間中的《從0開始學架構》專欄。
針對這四個問題，我想談談我的看法。因為在公司我的職責之一就是架構師，當然了，這個架構師並不是十分的專業。另外，對於架構師這個職位，沒有個五到六年的積累稱不上真正的架構師。
一、架構設計的目的是什么
針對這個問題，在我看來，為什么要架構設計，用一句話來概括就是:"架構設計的真正目的是為了解決軟件系統的復雜度帶來的問題"。
任何系統最開始都是非常簡單的，比如像我在這家公司開發的第一個項目智能酒店系統，最開始僅僅只是房態圖、會員、預定、報表、房價方案、房型、酒店、角色、員工、部門等不是特別復雜的功能，這些不是特別復雜的功能在現有的開源項目，有不少可以找到現成的解決方案可以節省很多時間。最早期看起有點復雜，實則不是特別復雜，到后來與對應的智能門鎖系統綁定在一起，就慢慢變的開始復雜起來。當系統越來越龐大變的耦合性高、性能低下時，這時就不得考慮重構。即便是重構也需要十分謹慎，因為既要保證重構能解決這個問題，同時也要保證項目在線上的正常服務，所以這個過程就需要循序漸進。在這個循序漸進的過程中，一開始就得仔細設計。
怎么個仔細設計法?
我個人結合之前的經驗，歸納為如下幾個辦法?
1.流程的梳理(主要是理清邏輯，看那些流程可以剔除或者是優化，除此之外，最好還是結合數據庫，將表的邏輯理清，利於分庫分表方案的進行);
2.根據最開始的文案(什么可行性方案、需求分析、概要設計、詳細設計等)，重新審慎;
3.代碼結構梳理(主要是項目結構(一些分包之類是否合理，比如像filter的話，通常放在cn.companyname.projectname.filter這個包下,同時也包括代碼是否規范,這個可以參考現有的阿里巴巴Java開發手冊)，同時這個梳理也是為了衡量是否有分模塊的必要或者是是否放棄單體轉向微服務的必要，當然了，也包括如果要這樣做，所花費的成本是否值得;
二、架構設計的常見誤區
1.不做架構設計的系統難道就跑不起來嗎?
不做架構設計的系統同樣也是跑的起來的，也能正常提供服務。比如敏捷開發為例，敏捷開發以用戶的需求進化為核心，一開始並沒有一個整體的架構思路，誰都不知道最后的項目會變成怎么樣，因為一切以用戶的需求進化為主。比如當初在開發智能酒店系統的時候，我們誰都沒有想到將其與智能門鎖綁定在一起。
另外順便說說敏捷開發的核心原則，給大家普及一下。
敏捷開發的核心原則有這么幾個?
（1）主張簡單；
（2）擁抱變化;
（3）可持續;
（4）遞增變化;
（5）投資最大化;
（6）有目的的建模;
（7）快速反饋;
（8）輕裝前行;
2.設計良好的架構能促進業務發展嗎?
這個問題可以分兩個角度來看，好的和壞的。
好的角度來看，項目之初，良好的架構可以促進項目的良性發展，人無遠慮必有近憂，設計之初將遠的近的都考慮進來，最后會使得項目朝着好的方向發展，同時也會降低項目所投入的時間、金錢、人員等成本。
壞的角度來看，對於軟件這個多變的玩意而言，很少有人能將所有的方面考慮到，即便考慮到了，還會有些遺漏，有一句話說的好，計划跟不上變化。就比如之前某家公司產品經理要求該程序員做出app背景根據手機殼來變色那樣的變態需求。從這個例子可以看出，需求具有不確定性，這個不確定性不僅僅與人員有關，也與業務在實際上為客戶服務有關。比如淘寶為例，淘寶剛開始，肯定沒有現在的高性能、高並發、高可用等。演變都是根據實際情況而定，根據實際的情況采取不同的措施。
比如在上家公司做的是辦公系統，辦公系統對於性能方面的要求肯定不及電商。如果對一個對性能要求不高的系統采用高性能、高並發相關的措施是不是有點不合適宜，因為這些都是要燒錢的，從老板的角度看，最大程度降低成本，做出客戶滿意的產品。至於性能方面的(只要達到用戶的期望，用的時候不卡頓就行)要求不高。
三、不是每個系統都需要做架構設計?
這里我引用李運華先生的觀點。李運華先生對此是這樣理解的？
他認為這是知其然不知其所以然，系統的確是要做架構設計，但卻不知道為什么要做架構設計，反正就覺得大家都要做架構設計，所以做架構設計肯定沒錯。
這樣的架構師或者設計師容易走入生搬硬套業界其他公司已有的架構歧路。一旦強行引入，很大可能會發現架構水土不服，或者運行起來很別扭，最后往往不得善終，要么推到重來，要么不斷重構。
以此可以回答，系統是需要做架構設計的，前面說過架構設計是為了解決軟件復雜度問題，項目之初，軟件架構應該是簡單、能實現業務這兩個目的。再比如晚清時期洋務運動的失敗，根本原因是因為不適合當時的中國國情。對於架構師而言，業界的確有很多不同或者大體相似的解決方案，但是究竟適合不適合公司，需要慎思。
四、為了高性能、高可用、可擴展，所以要做架構設計?
通常有這種觀點的人，不算是真正的架構師，因為不是每一個系統都需要達到這三個條件，或者是就算系統達到這三個條件，最終不讓客戶或者是老板滿意，那也是白搭。
李運華先生，對此的看法是:如果架構師往往有“為了高性能、高可用、可擴展，所以要做架構設計”這樣的想法並在實際當中這么做，那么將非常有可能會給項目帶來巨大的災難。
為什么會這樣呢?因為這類架構師不管三七二十一，不管什么系統，也不管什么業務，上來就要去“高性能、高可用、高擴展”，結果就會出現架構設計復雜無比，項目落地遙遙無期，團隊天天吵翻天等各種糟糕的現象，費盡千辛萬苦，費盡九牛二虎之力將系統整上線，卻發現運行不夠穩定、經常出問題，出了問題難以解決，排查問題困難，加個功能要改一個月或者兩個月。
我想有部分公司經常加班，與這個也許有一定的關系。
小結：
最后還是覺得要強調最開始說的那句話，架構設計的真正目的是為了解決軟件系統的復雜度帶來的問題。同時補充一句，不是為了追求所謂的高大尚。