按照正常的互聯(lián)網(wǎng)玩法，產(chǎn)品經(jīng)理原型畫好進(jìn)行需求評審，評審?fù)旰?#xff0c;需要把需求丟給技術(shù)經(jīng)理，或者技術(shù)負(fù)責(zé)人，進(jìn)行一整套的概要設(shè)計，然后針對概要設(shè)計評審，概要評審后進(jìn)行開發(fā)。這次咱們一起說說概要設(shè)計的體系結(jié)構(gòu)。了解下套路。

軟件系統(tǒng)設(shè)計

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

我們平常做開發(fā)設(shè)計嗎？

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

拿這鍵盤直接干。

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

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

做設(shè)計的時候，開發(fā)人員在考慮？還是技術(shù)經(jīng)理在考慮？

用什么方法做？

瀑布流程（互聯(lián)網(wǎng)直接忽略）

需求確定的基礎(chǔ)上，系統(tǒng)設(shè)計的方方面面設(shè)計的都很全面，把每個階段都有非常嚴(yán)格的驗證條件，在主流的大型軟件的開發(fā)方式。

基于原型，快速迭代（互聯(lián)網(wǎng)常用）

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

具體設(shè)計什么

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

• 體系結(jié)構(gòu)設(shè)計
  1.指明了一個系統(tǒng)是什么，它是整個軟件中最本質(zhì)的表現(xiàn)

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

2.應(yīng)當(dāng)設(shè)計的很穩(wěn)定

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

3.設(shè)計的原則

3.1 適應(yīng)性

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

3.2 結(jié)構(gòu)穩(wěn)定性

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

3.3 擴(kuò)展性

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

3.4 是不是所有的系統(tǒng)在設(shè)計的時候都要考慮擴(kuò)展性

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

3.5 可復(fù)用性

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

• 表結(jié)構(gòu)設(shè)計

方法論

表結(jié)構(gòu)設(shè)計

性能擴(kuò)展性考慮

• 系統(tǒng)的模塊設(shè)計

• 原型界面設(shè)計

• 設(shè)計模式

• 數(shù)據(jù)結(jié)構(gòu)和算法

PS：在之前也是不做設(shè)計的，但是做過設(shè)計的后明顯是跟不做設(shè)計有很大的區(qū)別的。很多提前設(shè)計的好，做設(shè)計很容易可控。不管大家對設(shè)計的理論有多少，設(shè)計是必須的。凡事預(yù)則立不預(yù)則廢。設(shè)計是為了讓開發(fā)，測試人員，產(chǎn)品經(jīng)理（設(shè)計沒有偏差）。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。