需求前提：
- 需求目標是什麼
- 需求研發性價比；工期是否合適
- 產品業務邏輯是否：自洽（自身的邏輯推演是否正確，或者是能否形成完成閉環）
- 需求功能拆分細粒度，並且是否保證每個功能點都可以實現
- 功能實現的技術選型
如果以上5點還沒有完全確定說明我們對於需求的前期準備工作還不夠完善；強烈建議不要進入下一步流程。
整體的流程如下流程圖所示：
正文
項目整體設計/系統架構設計
首先需要闡述項目整體設計和系統架構設計不一定等同；它是系統架構的重要一環。如果是新項目開發；它一般包括以下部分：
硬件和資源申請：需要業務方提前規劃未來1-2年需求未來是否要支持高併發方案，以及TPS/QPS範圍。以此爲基礎制定高併發的方案以及是否要考慮容災，高可用設計。（爲什麼需要業務方來規劃：如果業務上不存在這些要求，那麼花很大的精力去實現這些就會出現：輸入高於產出，簡單而言就是性價比不高）
業務難點分析：將業務難點分析轉化成技術難點實現。如千人千面的UI和查詢，靈活的業務配置等。我們需要在模塊設計做額外的處理或者引入一些未用過的中間層來解決，這些都是未知的風險。在整體設計以及風險評估時都需要考慮進去。
數據持久化解決方案：需要考慮業務數據的特徵來選擇；如短期內數據量會很大，但是並不屬於熱點數據，那麼我們可以考慮數據歸檔的方式。不管時技術還是資源成本都較低；如果數據量很大又是熱點數據，那麼則可以考慮分佈式數據庫如ddm如果熱點數據不涉及update那麼也可以引入ES來做query等。（需要注意的是，引入未知中間層不管服務提供商說得如何天花亂墜我們都需要加入到風險評估因素中）
技術選型：根據業務複雜度以及模塊功能劃分，選擇合理的軟件架構模式（條條大路通羅馬，不一定需要最好的一定要最合適的）如業務流程較多變或者較長，可以用事件驅動模型實現，簡單一點的用狀態機，複雜一點的則可以使用工作流。開發語言選型：一般推薦生態較成熟以及人力成本較低的，方便日後的維護以及擴展。（如JAVA+spring框架）
整體設計文檔輸出：在以上四步完成之後，項目的前期輪廓基本出來了，這時需要項目owner進行設計文檔輸出，推薦採用物理部署圖與業務流程圖相結合的方式進行技術文檔留底。同時也可以在團隊成員以頭腦風暴的方式進行討論最終進行定型。
領域模型與DB設計
領域模型概念：業務對象模型（也叫領域模型 domain model）是描述業務用例實現的對象模型。它是對業務角色和業務實體之間應該如何聯繫和協作以執行業務的一種抽象。業務對象模型從業務角色內部的觀點定義了業務用例。該模型爲產生預期效果確定了業務人員以及他們處理和使用的對象（“業務類和對象”）之間應該具有的靜態和動態關係。它注重業務中承擔的角色及其當前職責。這些模型類的對象組合在一起可以執行所有的業務用例。（簡單來說就是：業務的抽象）
爲什麼需要將領域模型和DB設計結合一起闡述；在領域模型中抽象概念和數據的關係以及約束；如是一對一還是一對多，多對多的關係是非常重要的一環。數據庫結合領域模型做映射轉化（ORMapping）需要重點關注：
數據庫中表字段，相同的概念在項目中應該統一
不可避免數據庫爲了減少過多的查詢會進行一些必要字段的冗餘，但是不能過度冗餘需要進行平衡
數據庫的職責應該保持單一性，只進行數據的持久化。不應該把業務邏輯加入到數據庫中；不利於後期維護以及對於功能點的增加導致擴展性較低，並且容易導致因爲業務不熟悉產生不必要的bug
數據的刪除應該只做邏輯刪除，不做物理刪除。方便數據的追溯還原
數據庫索引設計合理性分析
以上5步完成基本上存儲方案以及底層的數據結構就成型了。這時需要通過double check或集中評審方式進行推敲；最終沉澱爲領域模型設計文檔。
API接口設計
一個好的api接口設計是在業務需求中抽象出獨立的功能點並在業務需求與系統實現的平衡中找到一個最佳的點；既要考慮後續業務的擴展性也要對系統的安全性，可用性，擴展性做保障。除開主幹正向流程外，也需要對逆向流程以及異常流程進行考量。
api接口的三種使用場景：
提供給前端頁面使用
系統內部模塊之間的調用
提供給外部使用也就是openAPI
api接口使用注意點：
非對外公開的api接口需要對接口進行權限隔離以及驗證
對外公開的api接口。如提供給外部查詢的則要考慮網絡攻擊（網關層處理，這裏不進行贅述）。一般對外公開的接口不直接對映射到DB，可以通過緩存或者中間層的方式來提高系統的併發能力。
-
基於數據交互緯度進行api接口設計
數據的推拉模式
同步還是異步
是否需要削峯（MQ）
數據是否需要保證強一致性
api定義完成基本項目研發的前中期工作就算完成了。對於核心功能api設計需要整理詳細的需求背景對應的功能點拆分的映射，研發設計文檔以及詳細的流程圖進行設計評審並進行文檔留底。
代碼實現設計
Code基本上是對前面定義的api接口進行靈活實現。
主要有以下幾大原則：
單一原則（一個類或者一個方法只負責一項職責，儘量做到類的只有一個行爲原因引起變化
里氏替換原則：子類可以擴展父類的功能，但不能改變原有父類的功能；（本質其實就是java的多態）（目的：增強程序的健壯性）實際項目中，每個子類對應不同的業務含義，使父類作爲參數，傳遞不同的子類完成不同的業務邏輯。
依賴倒置原則 面向接口編程；（通過接口作爲參數實現應用場景）抽象就是接口或者抽象類，細節就是實現類含義：上層模塊不應該依賴下層模塊，兩者應依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象；通俗點就是說變量或者傳參數，儘量使用抽象類，或者接口；接口負責定義public屬性和方法，並且申明與其他對象依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯
接口隔離 建立單一接口；（擴展爲類也是一種接口，一切皆接口）定義：a.客戶端不應該依賴它不需要的接口；b.類之間依賴關係應該建立在最小的接口上；簡單理解：複雜的接口，根據業務拆分成多個簡單接口；（對於有些業務的拆分多看看適配器的應用）接口的設計粒度越小，系統越靈活，但是靈活的同時結構複雜性提高，開發難度也會變大，維護性降低
迪米特原則 最少知道原則，儘量降低類與類之間的耦合；一個對象應該對其他對象有最少的瞭解
開閉原則 用抽象構建架構，用實現擴展原則；
設計模式本身也是根據這6大設計原則衍生而來，所以只要對設計原則理解清楚了，我們運用各種設計模式時才能體會其真正的價值以及含義
總結
上述講述的這麼多步驟核心含義是：
需求含義：需求訴說時，對需求進行剖析明白其後面的真正含義（痛點是什麼）
需求拆分：對一個大的需求進行功能點拆分。是否都可以正確實現（功能是什麼）
api接口設計：從業務緯度對接口進行抽象，在滿足業務的同時保證系統的可用性，擴展性，安全性（實現是什麼）
文檔的沉澱：編寫的在好的代碼也經歷不住時間的摧殘，技術在進步也許當時編寫的時候是用的最新的技術，也許過一段時間最新技術就變了。閱讀文檔永遠比直接閱讀代碼來的效率高。