一、系統設計

根據工程實踐經驗，系統設計總體來說可以精簡提煉分為兩個核心階段，即總體設計和詳細設計。

1、總體設計

總體設計的主要任務是把需求分析得到的結果轉換為軟件結構和數據結構，也就是確定軟件的主體系統結構。

設計軟件結構的具體任務是將一個復雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關系、確定模塊間的接口和人機界面等。

概要設計方法的主要目標是根據特定維度確定各個子系統和模塊的劃分，將由一個或多個功能(或目標)密切相關或相似的應用程序所組成的程序集合抽象出來。根據經驗概要設計方法主要包括模塊化方法、功能分解方法、面向數據流和面向數據結構的設計方法。按照面向服務架構（SOA）或者比較時髦的觀點，概要設計的主要工作就是提取和整合微服務及業務邏輯，按照領域抽取展示層，最終拆分出功能獨立的子系統。舉例來說，按照一般的模塊化或者功能拆分方法，我們可以將一個完善的電商系統分解為商品、庫管、訂單、支付、財務、結算、配送、搜索、CRM、虛擬貨幣、優惠票券、短信、郵件、活動等子系統。而子系統可以再次按照模塊或者功能細分，比如訂單系統可以按商品品類或者活動類型或者線上線下等維度拆分；支付系統可以按照內外部支付方式、支付和風控策略、支付模式（如跳轉或直連等）等不同維度進行劃分。從SOA的角度看，不論子系統劃分維度是什么，SOA都會對各種服務進行布局和整合，發布服務和數據契約，其最主要的目的就是對子系統服務進行復用。當然，SOA如何和子系統設計布局和整合聯系起來這是另一個話題了，本文不展開討論。

2、詳細設計

細節決定成敗(Idea is cheap,detail is devil.)，詳細設計是實現系統模塊的關鍵步驟。

程序=算法+數據結構，雖然我認為這個公式不完全正確，但是突出了算法和數據結構的重要性。

詳細設計的主要任務就是根據總體設計中確定的業務子系統，設計每個子系統功能或模塊的實現算法和數據結構，但根據一般的業務系統開發經驗，詳細設計涉及的具體內容可能還包括數據庫設計、界面設計、子系統互聯設計等。

詳細設計非常考驗程序員的基本編程水平和經驗。我認為任何詳細設計的最終目標都是通過可編程的手段實現軟件系統，所以，對于開發人員，代碼是第一重要的作品，其次才是文檔，手冊，圖表，再其次是PPT等等這些副產品。

在實現業務子系統的過程中，必然會涉及到各種方法論，比如面向過程，面向對象等等。那么通過哪種方法論如何實現一個可正常工作功能強大適應變化的子系統呢？

在系統具體實現這一塊，我個人接觸最多的是面向對象編程（OOP）。成功設計開發一個子系統，我的個人開發經驗可以總結為如下幾條：

a、分而治之，劃分模塊，子系統還可以拆分子系統，服務還可以拆分子服務，這里涉及到一個粒度的問題，非常考驗開發者的水平和經驗，否則很容易過度設計

b、分層，這個不用說了，如果你真正理解分層的含義，那么在很多情況下，N層不如經典三層，誰寫誰知道

c、保證隔離，劃清界限，不要過多假設，不要拖泥帶水，任何模塊或服務只做它該做的事情

d、實現隔離的最佳方法，就是針對接口，而不是對具體實現編程(Programming to an Interface, not an Implementation)

e、多態，多態，多態，如果一定要復用類，請優先使用對象的組合而非繼承

f、提取變化劇烈的變化點，定期重構，核心業務邏輯必須單元測試

g、UI變化最大，其次業務邏輯，而且很多時候UI變化會直接影響后端業務邏輯，所以，你的接口設計要向UI和業務邏輯傾斜，反而是基礎框架和基礎服務非常穩定，不需要過度設計

做到上面這幾點，絕大多數的開發問題都會迎刃而解，反正在我多年開發經歷中屢試不爽。

當然，歸根結底，成功的子系統的設計與開發還是看具體開發者的水平，如果邏輯和抽象能力差，或者不認真沒有追求看上去就不那么讓人放心，說什么都是白搭。

二、平臺化設計

我們可以把以提供統一的公共服務為主要職責的軟件或系統叫做平臺軟件。比如常見的框架基礎平臺、應用管理平臺、工作平臺（OA系統等）、MDM、運維平臺、財務平臺、結算平臺、支付平臺、配送平臺、決策平臺、客戶管理平臺、CTI平臺、開放平臺、云平臺等等。

縱觀軟件發展歷程，圍繞著“復用”，各種方法論和工具層出不窮，比如：結構化開發中，函數和過程（表示一段代碼）的復用；面向對象設計（OOP）中的類和對象的復用 ，COM和COM+中的組件標志著模塊的復用；SOA架構中某個業務服務（子系統）的復用等等。

主流的軟件開發模式中，復用成了系統設計的一個重要目標，平臺化是復用軟件產品的一套成熟解決方案，開發和運營的性價比也較高，而且相對有利于擴展。

為什么說平臺化設計有利于擴展呢？下面的段落中我將講一個發生在自己身上的真實案例。

三、多商戶或多租戶系統

兩年前某司新擴張了業務，大致需求就是相當于注冊一個新公司同時該新公司可以使用已有的很多系統，但某些核心業務（如財務等）需要獨立運營，然后就涉及到我這里說講的多商戶或多租戶的系統。

平臺化的軟件產品有多種多樣，其中，又以多商戶或多租戶的系統設計與實現最為復雜，而且隨著需求的變化，擴展性很容易成為瓶頸，多商戶或多租戶的系統數據存儲我曾經有過簡單總結。

具體到某司的系統擴展，我給出的是兩種方案，方案一是可以為新公司獨立部署一套應用實例然后修改配置搞定，方案二是可以通過增量增加代碼重新實現一遍已有的功能。

從維持系統穩定的角度，兩種方案在理論上而言都相對的不會改動原有系統的實現代碼，第一種直接拷貝原有的部署結構重新實施改改數據庫配置就行了，第二種則是不改動任何已有代碼而是通過增加新代碼實現功能（這種不改動任何已有代碼僅限理論上，考慮到業務復雜性，可能還是需要對已有邏輯做些微調）。對于這兩種實現方案，很顯然會有人有不同意見，好了，我知道你們要說重復是魔鬼，不要重復你自己等等等等。要是在2010年之前，我一定也有類似的看法，我甚至還可能寫篇博客之類的洋洋灑灑批駁一番，但是經過多年工作和編程實踐考驗，再碰到有人說重復我就呵呵對待了。

無數事實證明理論和實踐不是一回事，歪果仁也流行說theory is ugly,idea is cheap,talk is very cheap...所以我們需要大膽實踐，驗證口頭上的理論在現實環境下到底行不行得通。

如果團隊人員充足，第一種簡直是為了擴展性而量身定做的，看上去只是增加了部署實施和后續維護的成本而已。但是如果人員不足，或者變化劇烈系統未來走向依然不確定，從維護角度，個人倒是傾向選擇第二種方案，因為通過數據共享和可擴展配置然后只維護一套系統，我實在想不到不使用這種方案更好的理由了。

最終我選擇了第一種方案，一份代碼配置成兩套系統。^_^ Yes,it works.兩個系統目前運行穩定。

這是我兩年多前近一個月的親身實踐，最大的收獲是，系統實現要高度可配置可運維，而且后臺管理工具要開發完備，一套系統按實例多次部署確實是很有效可行且實惠的解決方案。

四、通用架構基礎服務

在概要設計和詳細設計過程中，不論業務、方法論、工具或框架等外部條件怎么變化，從各個（不同）系統中總是可以抽象出公共的相對穩定的框架工具或服務，比如分布式緩存服務、消息隊列服務、通用數據訪問代理DAL（提供訪問數據模型和后端數據服務API實現對數據庫的一致性訪問，如果分表分庫了，也包括DBRoute功能，不能簡單等同于ORM），企業服務總線（ESB）、分布式文件系統、通用日志服務等等。這些基礎技術服務不同于業務系統，也不同于公共平臺服務（架構基礎服務可供公共服務調用），因為它們和多變的特定業務邏輯無關，相對偏重于底層技術，對技術要求較高，開發和運維這部分服務的都是水平較高的技術型選手為主。一般能獨立造輪子出來的公司還是比較有技術含金量的，雖然我也碰到過只發明卻不能用或者一用就有無數坑的團隊。我認為如果沒有這部分通用架構基礎積累，各個子系統各自為戰很可能會造成運營和管理上的難題。

總結

這是我個人從業10年的系統設計與開發經驗的粗淺總結，B/S和C/S結構的開發都通用。在很多人看來可能更多偏重于方法論，我所知道的絕大多數開發人員更喜歡討論技術細節的干貨，比如幾年前的自己，更多的偏重于“小節”，比如記錄學習某某編程語言的語法糖，某某流行框架的實踐，某某數據庫操作的奇技淫巧，某某算法和數據結構的妙用或誤用，某些新技術的使用經驗之類。

但是，我個人認為，當你真正從專注細節的小兵成長為可以獨當一面的大將后，你可能也會跳出這些“細枝末節”，從系統和架構的角度，把握全局，全面看問題。

難忘的2017即將過去，感謝志同道合的人，每一年，我們都要有收獲和進步，低頭沉默更堅定。Coding for fun.

祝大家新年快樂。

總結

以上是生活随笔為你收集整理的大道至简，系统设计和模块划分的实用经验之谈的全部內容，希望文章能夠幫你解決所遇到的問題。

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