1設計方案格式

現在的系統有什麼樣的問題需要解決，業務上要達到的目標是什麼。

技術需求的話主要是目前技術上哪些痛點：是無法靈活支援業務需求變化，還是效能有問題，還是流程上有缺陷等等。

也可以畫圖表示一下系統現狀，現在的服務架構、底層商品模型、流程等。

本次專案需要改動哪些地方，是全新做乙個交易流程（體驗專案預約）；還是需要要改到商品模型，導致全流程重做（洗浴改版）；還是只需要改 c 端展示，不涉及底層商品模型及交易流程（足療改版），還是新增加一些功能，對現有流程不影響（洗浴出票機）等。

如果大專案涉及到的改動點比較多，要做乙個思維導圖將所有相關的點列出來。

本次專案比較重要的一些方案，這裡可能會有討論過多個方案，盡量寫上每個方案的優缺點，選擇哪個方案以及原因。

商品模型，spu 與 sku 劃分，現在的劃分能否更好的支援**庫存與優惠等？良好的底層商品模型抽象能更好的適配適應當前業務並服務未來需求，不好的抽象會導致各種補救方法，導致系統補丁太多。

庫存模型是什麼，庫存如何與 sku 掛鉤？

**模型是什麼，**要不要與商品系統解耦開？底層資料結構是什麼？現有的模型能更好的支援各種展示需求嗎？比如列表頁起價，詳情頁**範圍等。

上單要不要接審核，不接審核有什麼風險，後續有問題了能不能快速接入，接入審核了線上線下資料一致性如何保證，b 端商戶體驗如何保證等。

對接第三方時，第三方超時、返回錯誤怎麼處理？邊界問題如何處理？任何介面任何流程第三方不可用怎麼處理？有什麼樣的降級措施？

涉及多個可選方案的，**形式的方案對比。詳細列出每個方案的描述及優缺點，目前選擇了哪個方案以及原因。

用例圖，主要用於大專案。

改動點的思維導圖。主要用於涉及業務團隊比較多，對流程改動比較大的。一方面可以對所有改動點有乙個全域性檢視，另一方面也可以避免遺漏某些場景。

服務架構圖。整體設定系統架構是怎麼樣子的，包括接入層、聚合層、領域層、資料層，每層都有哪些服務，服務之間的呼叫關係。

序列圖。主要用於專案流程性比較強的，如與第三方有訂單互動的，詳細標註系統間的互動。

狀態機。主要用於訂單狀態扭轉。

資料庫實體關係圖。主要的用於展示商品、**、庫存模型。如果有新建表，要附上建表語句。

列出涉及到的所有服務，涉及包括但不限於以下

新增服務或介面

修改服務

lion 配置需要修改

下游需要擴容的服務

上下游只需要公升級 api

外部需要提供的介面，或者工具類等

需要對外部團隊提供的介面，主要指向外部團隊提供的介面，以及為前端提供的介面。

資料模型有沒有變，有變的話如何相容歷史資料；是不是要刷資料，如果要的話刷資料的方案是什麼；要不要雙寫，雙寫的方案是什麼，如何保證資料一致性。

老訂單如何相容，不相容展示會不會有問題，未消費完的訂單要不要特殊處理等。

服務是否需要灰度上線，如果不灰度會有什麼樣的風險；灰度是按機器、使用者、商戶哪種策略，何時灰度多少量，何時全量。

回滾策略是什麼，如果涉及到多個服務，不同服務回滾流程是什麼。

列出所有需要感知到的外部系統，如果外部團隊也有開發工作量的，則附上外部團隊方案文件鏈結以及負責人，排期等。

也有可能涉及到外部資源申請，如申請訊息主題、簡訊觸達模板、商品型別、訂單型別、結算型別等，可以附上申請負責人，進度，以及申請到的資源。

如果是交易流程相關的服務，可能涉及到的團隊有：商家後台、旺鋪寶、商家後台上單、阿波羅主方案、泛商品系統、前端、支付、訂單、券、退款、結算、優惠、第三方、客服、bi、 ugc、poi、**、搜尋推薦等。

需要考慮到對本系統模組的影響：庫存、訂單、**、商品、觸達。

涉及到共有哪些改動，每個改動點需要的大概工作量，以及排期。

需求改動較大的，或邏輯較為複雜的地方，邊界條件，需要測試同學重點關注的點。