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

---

一、【強制】存儲方案和底層數據結構的設計得到評審一致經過，並沉澱成爲文檔。

說明：有缺陷的底層數據結構容易致使系統風險上升，可擴展性降低，重構成本也會因歷史數據遷移和系統平滑過渡而陡然增長，因此，存儲方案和數據結構須要認真地進行設計和評審，生產環境提交執行後，須要進行 double check。

正例：評審內容包括存儲介質選型、表結構設計可否知足技術方案、存取性能和存儲空間可否知足業務發展、表或字段之間的辯證關係、字段名稱、字段類型、索引等；數據結構變動（如在原有表中新增字段）也須要進行評審經過後上線。

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

三、【強制】若是某個業務對象的狀態超過 3 個，使用狀態圖來表達而且明確狀態變化的各個觸發條件。

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

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

四、【強制】若是系統中某個功能的調用鏈路上的涉及對象超過 3 個，使用時序圖來表達而且明確各調用環節的輸入與輸出。

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

五、【強制】若是系統中模型類超過 5 個，而且存在複雜的依賴關係，使用類圖來表達而且明確類之間的關係。

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

六、【強制】若是系統中超過 2 個對象之間存在協做關係，而且須要表示複雜的處理流程，使用活動圖來表示。

說明：活動圖是流程圖的擴展，增長了可以體現協做關係的對象泳道，支持表示併發等。

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

反例：用戶在淘寶付款過程當中，銀行扣款成功，發送給用戶扣款成功短信，可是支付寶入款時因爲斷網演練產生異常，淘寶訂單頁面依然顯示未付款，致使用戶投訴。

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

說明：單一原則最易理解倒是最難實現的一條規則，隨着系統演進，不少時候，忘記了類設計的初衷。

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

說明：不得已使用繼承的話，必須符合里氏代換原則，此原則說父類可以出現的地方子類必定可以出現，好比，「把錢交出來」，錢的子類美圓、歐元、人民幣等均可以出現。

十、【推薦】系統設計時，根據依賴倒置原則，儘可能依賴抽象類與接口，有利於擴展與維護。

說明：低層次模塊依賴於高層次模塊的抽象，方便系統間的解耦。

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

說明：極端狀況下，交付的代碼都是不可修改的，同一業務域內的需求變化，經過模塊或類的擴展來實現。

十二、【推薦】系統設計階段，共性業務或公共行爲抽取出來公共模塊、公共配置、公共類、公共方法等，避免出現重複代碼或重複配置的狀況。

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

1三、【推薦】避免以下誤解：敏捷開發 = 講故事 + 編碼 + 發佈。

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

反例：某團隊爲了業務快速發展，敏捷成了產品經理催進度的藉口，系統中均是勉強能運行但像麪條同樣的代碼，可維護性和可擴展性極差，一年以後，不得不進行大規模重構，得不償失。

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

說明：避免爲了設計而設計，系統設計文檔有助於後期的系統維護，因此設計結果須要進行分類歸檔保存。

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

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

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

• 肯定系統邊界。肯定系統在技術層面上的作與不作。
• 肯定系統內模塊之間的關係。肯定模塊之間的依賴關係及模塊的宏觀輸入與輸出。
• 肯定指導後續設計與演化的原則。使後續的子系統或模塊設計在規定的框架內繼續演化。
• 肯定非功能性需求。非功能性需求是指安全性、可用性、可擴展性等。

---

本文內容整理自《阿里巴巴Java開發手冊 1.4.0》，獲取完整版請關注如下公衆號後臺回覆關鍵字：手冊。