按照正常的互聯網玩法，產品經理原型畫好進行需求評審，評審完后，需要把需求丟給技術經理，或者技術負責人，進行一整套的概要設計，然后針對概要設計評審，概要評審后進行開發。這次咱們一起說說概要設計的體系結構。了解下套路。

軟件系統設計

軟件系統設計在很多人眼里就是寫文檔，寫文檔是一種負擔，其實系統設計頭腦風暴，是一種非常開心的事情。所以必須掌握什么是系統的設計。它里面有哪些方法論，如何去做一些系統設計。

我們平常做開發設計嗎？

才畢業回鄭州那幾年，都是一句話就是需求，開發完了河南本地連個測試人員都沒有，開發人員說開發完了就開發完了，直接拿給用戶進行測試。有的用戶直接罵娘，有的用戶用的感覺很不爽哭的（工作沒做完），有的用戶直接摔東西的。聰明的一點的用戶都直接聯系開發人員幫他來操作。直接測試都沒有，用戶就是測試人員，說實話7，8年前的告訴用戶怎么用，他怎么用。他感覺很神秘，這幾年隨著互聯網產品越來越多，智能手機的普及，大家對軟件的要求越來越嚴格了。很多之前的習慣的同事，現在都沒轉變過來，真是土，土的掉渣。后來其實也沒太關注設計，可能就是之畫個圖。直到后來跟第三方系統進行交互數據，剛開始草草的設計下，導致之后的2個月都沒好過。所以說系統設計是一項非常重要的工作。而不是老鐵們經常說的就是寫個文檔就行了。

拿這鍵盤直接干。

深思熟慮，考慮到多方的問題，在開始我們的編碼。

需求里面是一句話，直接就是干，別墨跡。

做設計的時候，開發人員在考慮？還是技術經理在考慮？

用什么方法做？

瀑布流程（互聯網直接忽略）

需求確定的基礎上，系統設計的方方面面設計的都很全面，把每個階段都有非常嚴格的驗證條件，在主流的大型軟件的開發方式。

基于原型，快速迭代（互聯網常用）

許多創業公司的老板真心喜歡，感覺業務可以進行快速的開發，其實在里面還是有很多的坑在里面的。很少有人基于瀑布來開發。其實快速迭代也變成了很多老板讓各位老鐵趕項目的理由了。我幾個億的單子，先讓用戶驗證，讓用戶體驗到，大家不能耽誤我們偉大的商業模式，就算是這種開發模式也是需要有文檔的，對設計不清楚的地方也會有很多，很多的坑在里面，包括后期的性能和擴展也好，如果前期底子沒有搭建好的話，后期傷筋動骨。隨隨便便改一個小功能可能要對程序進行傷筋動骨。但是這個時候老板是不會管你的，測試人員更不會管你，產品也不會管你，他們只知道我們滿足業務和需求。

具體設計什么

具體到底需要設計什么？如果系統沒有做好一個設計，如果你還是基于所謂的原型，快速迭代敏捷開發以這為借口的話，程序后期越來越大，越來越大的時候真心很傷，根本都不改你的系統，就比如說：銀行，社保里面的代碼基本是10年前的代碼，里面的問題一大堆，但是沒有人敢改，這也是設計部合理導致的一個毛病。

• 體系結構設計
  1.指明了一個系統是什么，它是整個軟件中最本質的表現

開發人員看文檔的時候，首先就要看體系結構。它是軟件系統最本質的東西，主體的形態，人的骨架就是體系結構。如果你設計的體系結構是個大猩猩，后期不管如何進化，如何發展，它始終無法變成一個人，只能是個猩猩。比如蓋房子，可能蓋高層，可能蓋土房，可能蓋平房，或者是窯洞，一開始就想蓋高層，它需要的材料，地基深度什么都是不一樣的。所以體系結構就需要了解軟件設計的本質。也可以說架構。

2.應當設計的很穩定

蓋到一半，要換地基是不是很悲催。開發的設計的時候一定要三思而后行。

3.設計的原則

3.1 適應性

????滿足用戶需求，達成商業的目的。而不是開發人員自己歪歪，高水平的設計人員就是設計出來剛剛滿足用戶需要的軟件，而不是不惜一切代碼設計出來一個最先進的軟件，沒有最好，只有最合適。打造閉環是最好的，對于很多互聯網項目，可能不是剛需需求，可能不是成熟的商業模式，如果非要進行閉環，試錯的機會都不給，開發的成本老板接受不了，老板無法快速推廣到市場里面。開發的功能越多，功能越強大的話，一旦業務發生調整的話，軟件不好發生變動。所以要分為很多個階段。開發和產品經理很多容易犯這個毛病，剛開始就設計都喜歡大而全，精而細。 產品經理經常愛說：『別人的系統都有這個功能，你為什么做不了！』，其實可以這么懟過去，給他上一課：『這樣的產品設計根本就不能滿足現階段產品設計的適應性！』

3.2 結構穩定性

????我們設計的要相對的穩定性，一定確定一定要相對的穩定性，如果經常變動，就相對于房子的地基，你看到那個房子蓋好后的地基經常發生變動。如果軟件經常發生，太悲劇了。體系結構設計的不穩定，范圍不清楚，如果一個系統剛開始是B2C，突然要變成B2B，表結構，系統模塊，界面，全部都要發生比較大的改變。整個項目變的很輪亂，需求不停的變動導致系統很混亂。導致開發人員不敢動代碼（牽一發動全身），都是復制一份 代碼。最后維護多份代碼。對于高水平的設計師都是有一定經驗的，可以預先知道那些需求是基本不變的，那些需求是可變的。
必須導出：可變需求和可變需求。
????舉個例子：之前項目中針對消息中心的設計，消息中心：對于用戶來說會有很多種類的消息。消息除了pc端，移動端也有很多的消息，物流消息，營銷消息，通知消息。當時就有一個問題， 實際的消息中心，就是接收到各種渠道的消息，然后分發到各個平臺（郵件，短信，推送，系統消息信息）。之前沒有消息中心，都是業務方自己各自來完成的。為了滿足原子性，原子是不可變的，消息中心需要做的就是按照業務方的需求把消息發送出去，發送到對應的渠道，短信。但是消息中心是在業務平臺之后設計的，業務平臺不可能因為發送消息修改自身的業務代碼。在消息中心專門設計了一個監聽模塊，監聽業務方的一個動作，這個模塊跟業務平臺是緊耦合的，事件監聽模塊隨著業務而變動，消息中心的核心功能不會發生變動的，因為功能很純粹就是發消息，收消息，推送消息。這就是當時如何保證穩定性的問題。在模塊上進行劃分。如果之后在需要拆分的話，直接把模塊進行拆分。監聽模塊，按照業務的變更進行變更。
???? 穩定性，就不會被業務需求方趕著走，項目是可控的。天天不用擔心老板又有新需求。

3.3 擴展性

????軟件在擴展新功能的難易程度。擴展性越好，適應變化的能力越強，尤其是敏捷開發，如果擴展能力不強的話，很容易進入一個死胡同里面去。區分可變動和不可變動。軟件體量約小，擴展能力越強，船小好調頭。為什么項目分階段，就是為了可擴展。系統的體量肯定受限業務的，越大的項目擴展性越難，所以要進行分布式（應用層，中間業務層，原子服務層），分層（控制層，服務層，數據訪問層），越是往下穩定。
????合理的業務模塊劃分，擴展的時候根據模塊進行拆分擴展。業務的邊界劃分。

3.4 是不是所有的系統在設計的時候都要考慮擴展性

????一次性項目，只要完成現階段的功能就可以了，例如兩個單獨的公司的對接接口，其實很多時候因為可能是一次性的，沒必要考慮擴展性，如果考慮可能就變成了過度設計。如果做開放平臺的話，肯定要考慮擴展性。

3.5 可復用性

????用一次還可以繼續在用，工具類，公共的組件。工具類一定設計的純粹（對使用環境沒有假設，少配置零配置，沒有依賴）

• 表結構設計

方法論

表結構設計

性能擴展性考慮

• 系統的模塊設計

• 原型界面設計

• 設計模式

• 數據結構和算法

PS：在之前也是不做設計的，但是做過設計的后明顯是跟不做設計有很大的區別的。很多提前設計的好，做設計很容易可控。不管大家對設計的理論有多少，設計是必須的。凡事預則立不預則廢。設計是為了讓開發，測試人員，產品經理（設計沒有偏差）。

總結

以上是生活随笔為你收集整理的『互联网架构』软件架构-软件系统设计（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

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