有網友花了兩個月時間做了一個 b2c 商城，技術棧是 sass、jquery、thinkphp，一套摸索下來後，遇到非常多的問題。例如：對項目開發流程等沒概念、不知道去哪裡查找相關資料。是以他提出來幾個問題：
- 項目開發流程的基本組成部分有哪些？
- 如何在初期确定項目整體的運作模型？
- 如何設計資料模型？
以下是這位網友在項目初期的一些腦圖，由于設計問題，其中退貨、優惠券、折扣部分最終并未完成：
針對這些問題，淘系技術架構師勇劍同學寫出本文一一解答。
對于項目開發流程，我的了解，與這位網友實際上大緻上是差不多的，不過一般團隊裡面，都會有業務、産品、服務端、前端、用戶端、測試等角色，是以相對整體的溝通成本會高很多，整體的流程大緻上是：需求評審、技術方案評審/項目排期、測試用例評審、開發、測試、功能預演、釋出上線、線上灰階/放量。
實際上這位網友所提到的 “設計整體業務流程” 這一步應該是在技術介入之前就要由産品與業務提前溝通确認好的。“設計資料模型” 應該歸屬到技術方案這一步裡面，是其中的一部分。
整個流程對于技術開發同學來說，重點需要關注需求評審、技術方案設計這兩大部分，簡單談一下我的一些看法。
關于需求，之前看過一段馬斯克的工作理念介紹，覺得非常不錯，講的是需求疊代的過程，建議按照下面五步：
- 制定需求的時候，讓你的需求别那麼蠢（哈哈，也就是希望需求盡量合理，不要做出來了發現沒什麼用）
- 嘗試删除部件或過程，這一步可以讓你知道最核心的部件與過程是什麼。
- 優化，隻有到了第三步，才是優化，不要第一步就優化，讓你的優化集中在必要的部件與過程上，這是很多工程師容易搞錯的地方。
- 加速前三部循環的時間，你的動作太慢了，更快一點～，在這前，不要加速
- 最後一步是自動化
前三步對于我們在一些業務需求的制定上，可以提供一些比較好的參考，在實際項目過程中，也讓我們思考什麼是我們的核心需求，把有限的人力集中到我們必須要做的事情上面去，拿到更好的成果。
另外一點是關于技術方案設計，我覺的是沒有一個固定的模版的，重點是要講清楚在整個技術設計過程中更需要關注的核心技術問題，包括但不限于技術選型、業務互動時序圖、實體狀态機、資料模組化、應用/實體/業務架構，以及高可用保障、穩定性風險等等。
如何在初期确定項目整體的運作模型？即對項目整體的前期設計？
這個問題的本質實際上是一個領域模組化的問題，回到題主的第一張圖，在領域模組化的時候，我的了解是，先要理清我們業務的核心實體，也就是領域實體，在這張圖裡面，我們可以清晰看出三部分：使用者、商品、訂單（當然也可以更細化到一些實體：購物車、物流單、評價等等，這裡隻是簡單舉例），展現在設計上，整個業務的應用架構必然需要三大中心：使用者中心、商品中心、訂單中心。當模型确認之後，模型自身的行為以及模型之間的關系也就随之确定。
題主的這個圖，看主要是用來介紹整體一些業務流程，包括：實體、使用者行為、邏輯判斷等等，對于這些建議是通過“時序圖”來描述相對會更好一點，可以相對更加清晰的來描述系統、對象、對象與系統的互動行為。
簡單畫了一下使用者與幾個系統的關系與互動，可以看出需要哪些系統、這些系統需要哪些能力、使用者如何與這些系統之間完成互動。
PS：這裡畫的不太全，忽略了所有異常邏輯的處理以及資料一緻性問題，包括在使用者建單之後，後續的支付流程、以及後續訂單的狀态機流程這裡都沒在詳細畫了，隻是簡單給個 Demo。
關于“使用者中心”這塊，注冊/登入/登出/修改個人資訊 這幾大部分維護在使用者中心是 OK 的，但是優惠券、訂單記錄查詢、訂單評論這幾部分放在這裡感覺不太合适，優惠券屬于營銷域，應該是歸屬于一個營銷域的“卡券”（coupon）子系統，由該系統提供根據使用者 ID 查詢優惠券的能力即可。訂單記錄及查詢維護在“訂單中心”會更合适一些，至于“評論”，也可以放到一個單獨的子系統裡面去。
簡而言之就是根據業務訴求确定系統的領域模型，再對各個領域進行職責劃分、功能拆解，之後就是逐漸完善各個子域了。整個項目的架子搭好之後，後續的功能擴充也會相對比較簡單。
如何設計資料模型？或者說怎麼設計資料表？
資料庫的設計第一步首先要搞清業務訴求，有時候不同的業務需求會導緻資料模組化存在較大的差異，這一點是我們需要在做設計之前明确的。
之後就是根據業務形态，确定領域實體，比如電商涉及到的商品、訂單、使用者等等，商品域内又包含SPU、SKU、類目資訊等等。
題主提到的根據前端功能需求來設計資料模型，對于簡單的需求來說，是可以的，但對于複雜業務如果這樣設計，後續如果前端功能需求發生變動，那麼對整個系統的改造也是災難性的，建議建立起一套穩健的領域模型，将前端需求與底層存儲做好防腐和解耦。在DB層的模組化做好适當的抽象、備援等處理，資料在系統裡面通過領域實體流轉，對于頁面隻是一個實體的VO渲染即可。
另外資料表的設計，需要考慮各方面因素，比如資料量的預估（是否需要分庫分表）、存儲方式（存儲技術選型）、有沒有熱點資料、預留未來擴充的可能性等等
關于 DB 模組化，建議采用 ER 圖來設計，資料表的關聯關系展現的會相對清晰一些。下面是一個簡單的 Demo
關于 MySql 資料庫方面的技術，推薦一本書：《高性能MySQL》
畫圖工具
最後關于畫圖這塊，推薦幾款比較好用的作圖利器哈：
- OmniGraffle： https://www.omnigroup.com/omnigraffle
- draw.io：https://drawio-app.com/examples/
- PlantUml： https://plantuml.com/zh/sequence-diagram