需求前提：

1. 需求目標(biāo)是什么
2. 需求研發(fā)性價比唐含；工期是否合適
3. 產(chǎn)品業(yè)務(wù)邏輯是否：自洽（自身的邏輯推演是否正確群凶，或者是能否形成完成閉環(huán)）
4. 需求功能拆分細粒度鸽照，并且是否保證每個功能點都可以實現(xiàn)
5. 功能實現(xiàn)的技術(shù)選型

如果以上5點還沒有完全確定說明我們對于需求的前期準(zhǔn)備工作還不夠完善胎署；強烈建議不要進入下一步流程睬关。

整體的流程如下流程圖所示：

image.png

正文

項目整體設(shè)計/系統(tǒng)架構(gòu)設(shè)計

首先需要闡述項目整體設(shè)計和系統(tǒng)架構(gòu)設(shè)計不一定等同嚣州；它是系統(tǒng)架構(gòu)的重要一環(huán)。如果是新項目開發(fā)共螺；它一般包括以下部分：

1. 硬件和資源申請：需要業(yè)務(wù)方提前規(guī)劃未來1-2年需求未來是否要支持高并發(fā)方案该肴，以及TPS/QPS范圍。以此為基礎(chǔ)制定高并發(fā)的方案以及是否要考慮容災(zāi)藐不，高可用設(shè)計匀哄。（為什么需要業(yè)務(wù)方來規(guī)劃：如果業(yè)務(wù)上不存在這些要求，那么花很大的精力去實現(xiàn)這些就會出現(xiàn)：輸入高于產(chǎn)出雏蛮，簡單而言就是性價比不高）

2. 業(yè)務(wù)難點分析：將業(yè)務(wù)難點分析轉(zhuǎn)化成技術(shù)難點實現(xiàn)涎嚼。如千人千面的UI和查詢，靈活的業(yè)務(wù)配置等挑秉。我們需要在模塊設(shè)計做額外的處理或者引入一些未用過的中間層來解決法梯，這些都是未知的風(fēng)險。在整體設(shè)計以及風(fēng)險評估時都需要考慮進去犀概。

3. 數(shù)據(jù)持久化解決方案：需要考慮業(yè)務(wù)數(shù)據(jù)的特征來選擇立哑；如短期內(nèi)數(shù)據(jù)量會很大，但是并不屬于熱點數(shù)據(jù)姻灶，那么我們可以考慮數(shù)據(jù)歸檔的方式铛绰。不管時技術(shù)還是資源成本都較低；如果數(shù)據(jù)量很大又是熱點數(shù)據(jù)产喉，那么則可以考慮分布式數(shù)據(jù)庫如ddm如果熱點數(shù)據(jù)不涉及update那么也可以引入ES來做query等捂掰。（需要注意的是，引入未知中間層不管服務(wù)提供商說得如何天花亂墜我們都需要加入到風(fēng)險評估因素中）

4. 技術(shù)選型：根據(jù)業(yè)務(wù)復(fù)雜度以及模塊功能劃分曾沈，選擇合理的軟件架構(gòu)模式（條條大路通羅馬这嚣，不一定需要最好的一定要最合適的）如業(yè)務(wù)流程較多變或者較長，可以用事件驅(qū)動模型實現(xiàn)塞俱，簡單一點的用狀態(tài)機姐帚，復(fù)雜一點的則可以使用工作流。開發(fā)語言選型：一般推薦生態(tài)較成熟以及人力成本較低的敛腌，方便日后的維護以及擴展卧土。（如JAVA+spring框架）

5. 整體設(shè)計文檔輸出：在以上四步完成之后，項目的前期輪廓基本出來了像樊，這時需要項目owner進行設(shè)計文檔輸出尤莺，推薦采用物理部署圖與業(yè)務(wù)流程圖相結(jié)合的方式進行技術(shù)文檔留底。同時也可以在團隊成員以頭腦風(fēng)暴的方式進行討論最終進行定型生棍。

領(lǐng)域模型與DB設(shè)計

領(lǐng)域模型概念：業(yè)務(wù)對象模型（也叫領(lǐng)域模型 domain model）是描述業(yè)務(wù)用例實現(xiàn)的對象模型颤霎。它是對業(yè)務(wù)角色和業(yè)務(wù)實體之間應(yīng)該如何聯(lián)系和協(xié)作以執(zhí)行業(yè)務(wù)的一種抽象。業(yè)務(wù)對象模型從業(yè)務(wù)角色內(nèi)部的觀點定義了業(yè)務(wù)用例。該模型為產(chǎn)生預(yù)期效果確定了業(yè)務(wù)人員以及他們處理和使用的對象（“業(yè)務(wù)類和對象”）之間應(yīng)該具有的靜態(tài)和動態(tài)關(guān)系友酱。它注重業(yè)務(wù)中承擔(dān)的角色及其當(dāng)前職責(zé)晴音。這些模型類的對象組合在一起可以執(zhí)行所有的業(yè)務(wù)用例。（簡單來說就是：業(yè)務(wù)的抽象）

為什么需要將領(lǐng)域模型和DB設(shè)計結(jié)合一起闡述缔杉；在領(lǐng)域模型中抽象概念和數(shù)據(jù)的關(guān)系以及約束锤躁；如是一對一還是一對多，多對多的關(guān)系是非常重要的一環(huán)或详。數(shù)據(jù)庫結(jié)合領(lǐng)域模型做映射轉(zhuǎn)化（ORMapping）需要重點關(guān)注：

1. 數(shù)據(jù)庫中表字段系羞，相同的概念在項目中應(yīng)該統(tǒng)一

2. 不可避免數(shù)據(jù)庫為了減少過多的查詢會進行一些必要字段的冗余，但是不能過度冗余需要進行平衡

3. 數(shù)據(jù)庫的職責(zé)應(yīng)該保持單一性霸琴，只進行數(shù)據(jù)的持久化椒振。不應(yīng)該把業(yè)務(wù)邏輯加入到數(shù)據(jù)庫中；不利于后期維護以及對于功能點的增加導(dǎo)致擴展性較低梧乘，并且容易導(dǎo)致因為業(yè)務(wù)不熟悉產(chǎn)生不必要的bug

4. 數(shù)據(jù)的刪除應(yīng)該只做邏輯刪除澎迎，不做物理刪除。方便數(shù)據(jù)的追溯還原

5. 數(shù)據(jù)庫索引設(shè)計合理性分析

6. 以上5步完成基本上存儲方案以及底層的數(shù)據(jù)結(jié)構(gòu)就成型了选调。這時需要通過double check或集中評審方式進行推敲夹供；最終沉淀為領(lǐng)域模型設(shè)計文檔。

API接口設(shè)計

一個好的api接口設(shè)計是在業(yè)務(wù)需求中抽象出獨立的功能點并在業(yè)務(wù)需求與系統(tǒng)實現(xiàn)的平衡中找到一個最佳的點学歧；既要考慮后續(xù)業(yè)務(wù)的擴展性也要對系統(tǒng)的安全性罩引，可用性，擴展性做保障枝笨。除開主干正向流程外，也需要對逆向流程以及異常流程進行考量揭蜒。

api接口的三種使用場景：

1. 提供給前端頁面使用

2. 系統(tǒng)內(nèi)部模塊之間的調(diào)用

3. 提供給外部使用也就是openAPI

api接口使用注意點：

1. 非對外公開的api接口需要對接口進行權(quán)限隔離以及驗證

2. 對外公開的api接口横浑。如提供給外部查詢的則要考慮網(wǎng)絡(luò)攻擊（網(wǎng)關(guān)層處理，這里不進行贅述）屉更。一般對外公開的接口不直接對映射到DB徙融，可以通過緩存或者中間層的方式來提高系統(tǒng)的并發(fā)能力。

3. 基于數(shù)據(jù)交互緯度進行api接口設(shè)計

   1. 數(shù)據(jù)的推拉模式

   2. 同步還是異步

   3. 是否需要削峰（MQ）

   4. 數(shù)據(jù)是否需要保證強一致性

api定義完成基本項目研發(fā)的前中期工作就算完成了瑰谜。對于核心功能api設(shè)計需要整理詳細的需求背景對應(yīng)的功能點拆分的映射欺冀，研發(fā)設(shè)計文檔以及詳細的流程圖進行設(shè)計評審并進行文檔留底。

代碼實現(xiàn)設(shè)計

Code基本上是對前面定義的api接口進行靈活實現(xiàn)萨脑。

主要有以下幾大原則：

1. 單一原則（一個類或者一個方法只負責(zé)一項職責(zé)隐轩，盡量做到類的只有一個行為原因引起變化

2. 里氏替換原則：子類可以擴展父類的功能，但不能改變原有父類的功能渤早；（本質(zhì)其實就是java的多態(tài)）（目的：增強程序的健壯性）實際項目中职车，每個子類對應(yīng)不同的業(yè)務(wù)含義，使父類作為參數(shù)，傳遞不同的子類完成不同的業(yè)務(wù)邏輯悴灵。

3. 依賴倒置原則 面向接口編程扛芽；（通過接口作為參數(shù)實現(xiàn)應(yīng)用場景）抽象就是接口或者抽象類，細節(jié)就是實現(xiàn)類含義：上層模塊不應(yīng)該依賴下層模塊积瞒，兩者應(yīng)依賴其抽象川尖；抽象不應(yīng)該依賴細節(jié)，細節(jié)應(yīng)該依賴抽象茫孔；通俗點就是說變量或者傳參數(shù)空厌，盡量使用抽象類，或者接口银酬；接口負責(zé)定義public屬性和方法嘲更，并且申明與其他對象依賴關(guān)系，抽象類負責(zé)公共構(gòu)造部分的實現(xiàn)揩瞪，實現(xiàn)類準(zhǔn)確的實現(xiàn)業(yè)務(wù)邏輯

4. 接口隔離 建立單一接口赋朦；（擴展為類也是一種接口，一切皆接口）定義：a.客戶端不應(yīng)該依賴它不需要的接口李破；b.類之間依賴關(guān)系應(yīng)該建立在最小的接口上宠哄；簡單理解：復(fù)雜的接口，根據(jù)業(yè)務(wù)拆分成多個簡單接口嗤攻；（對于有些業(yè)務(wù)的拆分多看看適配器的應(yīng)用）接口的設(shè)計粒度越小毛嫉，系統(tǒng)越靈活，但是靈活的同時結(jié)構(gòu)復(fù)雜性提高妇菱，開發(fā)難度也會變大承粤，維護性降低

5. 迪米特原則 最少知道原則，盡量降低類與類之間的耦合闯团；一個對象應(yīng)該對其他對象有最少的了解

6. 開閉原則 用抽象構(gòu)建架構(gòu)辛臊，用實現(xiàn)擴展原則；

設(shè)計模式本身也是根據(jù)這6大設(shè)計原則衍生而來房交，所以只要對設(shè)計原則理解清楚了彻舰，我們運用各種設(shè)計模式時才能體會其真正的價值以及含義

總結(jié)

上述講述的這么多步驟核心含義是：

1. 需求含義：需求訴說時，對需求進行剖析明白其后面的真正含義（痛點是什么）

2. 需求拆分：對一個大的需求進行功能點拆分候味。是否都可以正確實現(xiàn)（功能是什么）

3. api接口設(shè)計：從業(yè)務(wù)緯度對接口進行抽象刃唤，在滿足業(yè)務(wù)的同時保證系統(tǒng)的可用性，擴展性白群，安全性（實現(xiàn)是什么）

4. 文檔的沉淀：編寫的在好的代碼也經(jīng)歷不住時間的摧殘尚胞，技術(shù)在進步也許當(dāng)時編寫的時候是用的最新的技術(shù)，也許過一段時間最新技術(shù)就變了川抡。閱讀文檔永遠比直接閱讀代碼來的效率高辐真。