阿裡巴巴制定了這 16 條設計規約！

1、【強制】存儲方案和底層資料結構的設計獲得評審一緻通過，并沉澱成為文檔。

說明：有缺陷的底層資料結構容易導緻系統風險上升，可擴充性下降，重構成本也會因曆史資料遷移和系統平滑過渡而陡然增加，是以，存儲方案和資料結構需要認真地進行設計和評審，生産環境送出執行後，需要進行 double check。

正例：評審内容包括存儲媒體選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或字段之間的辯證關系、字段名稱、字段類型、索引等；資料結構變更（如在原有表中新增字段）也需要進行評審通過後上線。

2、【強制】在需求分析階段，如果與系統互動的 User 超過一類并且相關的 User Case 超過 5 個，使用用例圖來表達更加清晰的結構化需求。

3、【強制】如果某個業務對象的狀态超過 3 個，使用狀态圖來表達并且明确狀态變化的各個觸發條件。

說明：狀态圖的核心是對象狀态，首先明确對象有多少種狀态，然後明确兩兩狀态之間是否存在直接轉換關系，再明确觸發狀态轉換的條件是什麼。

正例：淘寶訂單狀态有已下單、待付款、已付款、待發貨、已發貨、已收貨等。比如已下單與已收貨這兩種狀态之間是不可能有直接轉換關系的。

4、【強制】如果系統中某個功能的調用鍊路上的涉及對象超過 3 個，使用時序圖來表達并且明确各調用環節的輸入與輸出。

說明：時序圖反映了一系列對象間的互動與協作關系，清晰立體地反映系統的調用縱深鍊路。

5、【強制】如果系統中模型類超過 5 個，并且存在複雜的依賴關系，使用類圖來表達并且明确類之間的關系。

說明：類圖像建築領域的施工圖，如果搭平房，可能不需要，但如果建造螞蟻 Z 空間大樓，肯定需要詳細的施工圖。

6、【強制】如果系統中超過 2 個對象之間存在協作關系，并且需要表示複雜的處理流程，使用活動圖來表示。

說明：活動圖是流程圖的擴充，增加了能夠展現協作關系的對象泳道，支援表示并發等。

7、【推薦】需求分析與系統設計在考慮主幹功能的同時，需要充分評估異常流程與業務邊界。

反例：使用者在淘寶付款過程中，銀行扣款成功，發送給使用者扣款成功短信，但是支付寶入款時由于斷網演練産生異常，淘寶訂單頁面依然顯示未付款，導緻使用者投訴。

8、【推薦】類在設計與實作時要符合單一原則。

說明：單一原則最易了解卻是最難實作的一條規則，随着系統演進，很多時候，忘記了類設計的初衷。

9、【推薦】謹慎使用繼承的方式來進行擴充，優先使用聚合/組合的方式來實作。

說明：不得已使用繼承的話，必須符合裡氏代換原則，此原則說父類能夠出現的地方子類一定能夠出現，比如，“把錢交出來”，錢的子類美元、歐元、人民币等都可以出現。

10、【推薦】系統設計時，根據依賴倒置原則，盡量依賴抽象類與接口，有利于擴充與維護。

說明：低層次子產品依賴于高層次子產品的抽象，友善系統間的解耦。

11、【推薦】系統設計時，注意對擴充開放，對修改閉合。

說明：極端情況下，傳遞的代碼都是不可修改的，同一業務域内的需求變化，通過子產品或類的擴充來實作。

12、【推薦】系統設計階段，共性業務或公共行為抽取出來公共子產品、公共配置、公共類、公共方法等，避免出現重複代碼或重複配置的情況。

說明：随着代碼的重複次數不斷增加，維護成本指數級上升。

13、【推薦】避免如下誤解：靈活開發 = 講故事 + 編碼 + 釋出。

說明：靈活開發是快速傳遞疊代可用的系統，省略多餘的設計方案，摒棄傳統的審批流程，但核心關鍵點上的必要設計和文檔沉澱是需要的。

反例：某團隊為了業務快速發展，靈活成了産品經理催進度的借口，系統中均是勉強能運作但像面條一樣的代碼，可維護性和可擴充性極差，一年之後，不得不進行大規模重構，得不償失。

14、【參考】系統設計主要目的是明确需求、理順邏輯、後期維護，次要目的用于指導編碼。

說明：避免為了設計而設計，系統設計文檔有助于後期的系統維護，是以設計結果需要進行分類歸檔儲存。

15、【參考】設計的本質就是識别和表達系統難點，找到系統的變化點，并隔離變化點。

說明：世間衆多設計模式目的是相同的，即隔離系統變化點。

16、【參考】系統架構設計的目的：

确定系統邊界。确定系統在技術層面上的做與不做。

确定系統内子產品之間的關系。确定子產品之間的依賴關系及子產品的宏觀輸入與輸出。

确定指導後續設計與演化的原則。使後續的子系統或子產品設計在規定的架構内繼續演化。

确定非功能性需求。非功能性需求是指安全性、可用性、可擴充性等。