下面這些內容摘自張開濤的書籍《億級流量網站架構核心技術》，推薦大家閱讀本書。
業務設計原則，主要有：
- 防重設計
- 冪等設計
- 流程可定義
- 狀態與狀態機
- 後臺系統操作可反饋
- 後臺系統審批化
- 文檔和註釋
- 備份
防重設計
比如，結算頁面要考慮重複提交的問題，還有下單時扣減庫存要防止重複扣減的問題。解決方案可以考慮防重key、防重表。而有些場景下如重複支付，是因爲有的電商網站同時支持微信支付、京東支付，渠道不一樣是無法防止重複支付的。但是在系統設計時，需要將支付的每筆情況記錄下來。
冪等設計
在交易系統中，經常會用到消息，而現有消息中間件基本不保證不發生重複消息的消費。因此，需要業務系統在重複消費時進行冪等處理。還有在使用第三方支付時，第三方支付會進行異步回調，也要做好回調的冪等處理。
流程可定義
如果接觸過保險業務，就會發現不同保險的理賠服務是不一樣的。在設計系統時就設計了一套專門的理賠流程模塊。而承保流程和理賠流程是分離的，在需要時進行關聯，從而可以複用一些理賠流程，並提供個性化的理賠流程。
狀態與狀態機
在設計交易訂單系統時，會存在正向狀態和逆向狀態，正向狀態，例如待付款、待發貨、已發貨；逆向狀態如取消訂單、退款等。正向狀態和逆向狀態應該根據系統的特徵來決定要不要分離存儲。狀態設計時應有狀態軌跡，方便用戶跟蹤當前訂單的軌跡並記錄相關日誌，萬一出問題時可回溯問題。
另外，還有訂單狀態的變遷，例如待支付、已支付待發貨、待收貨的遷移。要考慮要不要使用狀態機來驅動狀態的變更和後續流程節點的操作，尤其當狀態很多的時候使用狀態機能更好的控制狀態遷移。
還要考慮併發狀態修改問題，如一個訂單同時只能有一個修改；狀態變更的有序問題，以及狀態變更消息的先到後到的問題，如支付成功消息和用戶取消消息的時間差。
後臺系統操作可反饋
假如修改了某些內容後想預覽看最終效果，這就是希望得到反饋結果；還有就是在規則系統中，希望看到這些規則在系統數據下的反饋。因此，在設計後臺系統時，需考慮效果的可預覽、可反饋。
後臺系統審批化
對於有些重要的後臺功能需要設計審批流，比如調整價格，並對操作進行日誌記錄，從而保證操作可追溯、可審計。
文檔和註釋
在一個系統發展的初期就應該建立文檔庫，例如設計架構、設計說明書、業務規則說明書，程序猿在寫代碼時也應寫清楚註釋，不然會給其他的程序猿帶來理解上的障礙，並嚴重降低工作效率。
備份
一種是代碼備份，代碼要提交到代碼倉庫進行管理和備份。還有一種就是程序猿的備份，我們要確保一個模塊，至少有兩個程序猿對其是相當熟悉的。