複雜的問題，往往需要簡單的邏輯；
一、業務背景
業務開發是一件複雜且耗時的工程，所以最近幾年出了一個很火的概念叫做"低程式碼"開發，簡單的說就是開發人員通過簡單的"拖拉拽"配置，快速構建起業務應用，甚至一些業務人員可以自行操作，比如下面常用的一些功能；
- 資料包表：通過BI工具快速配置和生成相應的資料包表，降低資料統計的工作量；
- 業務表單：圍繞基礎的欄位庫能力，快速構建業務屬性的表單結構，避免頻繁的擴充套件版本；
- 審批管理：通過流程的靈活配置，動態管理各種審批場景，例如人事，財務，合同；
做這些業務設計時，核心思想是：把常用的邏輯進行封裝，流程設計為可配置，這樣即可在一定時間內應對業務的需求和變化，降低開發成本的支出，從而使研發更側重核心業務的管理和抽象封裝等內容。
二、資料包表
隨著業務的發展，資料包表通常都是系統的必備模組，以往都是在後端提供資料包表的模組，不過近幾年少有設計獨立的報表統計，都是基於雲服務的BI平臺快速實現報表的搭建：
- 業務欄位：通常報表的維度都是展示對應欄位的統計結果，所以業務庫的結構解析是基礎功能；
- 報表元件：提供基礎的報表元件，例如折線圖、柱狀圖、漏斗圖等，並設計初始化規則；
- 計算能力：日常資料分析的常用計算方法，基於加減乘除取模等，封裝更加靈活的計算策略；
- 報表頁面：通過可配置的頁面整合多個報表元件，報表元件可以根據佔比或者座標進行佈局；
關於資料包表的呈現方式其實有很多種，視覺化報表是最常見的，還有一些可能直接基於SQL統計進行定期彙總，以郵件的方式或者公司內部文件的形式輸出，解決問題的方式通常不止一種，要學會選擇相對合理的策略。
三、業務表單
SAAS服務或者常見的管理平臺，通常都提供自定義表單的建立能力，通過基礎欄位庫的組合，快速構建相應的業務表單結構，從而應對需求的多變性：
-
欄位庫：提供業務需求的欄位管理，並設計相應的規則約束，例如預設值、提示語、唯一性等等；
- 基礎：文字框、文字域、單選、複選、數字框；
- 進階：日期、時間、郵件、地址、三級聯動、貨幣與單位；
- 高階：自定義封裝，樣式管理與資料載入API；
-
表單庫：通過欄位庫組合構建相應的表單模板，從而對應業務的資料主體，進而實現業務的資料化管理；
- 表單結構：儲存表單中欄位的基礎配置和規則，以便頁面的回顯；
- 資料主表：表單對應的業務，建立相應的主表結構，即
biz-form-id概念； - 鍵值資料：表單中欄位和對應的資料錄入，即
key-value結構； - 資料索引：由於表單欄位的靈活配置，通常構建
No-SQL搜尋結構； - 資料回顯：基於表單配置的欄位，解析響應頁面的資料結構，實現資料回顯；
基於簡單的拖拉拽方式進行表單配置，可以快速生成業務需求的主體結構，只不過整個表單的配置和解析十分複雜，各個節點的管理也更加靈活多變，需要對流程不斷優化和模板設計，從而提高複用能力。
四、審批管理
報表和表單從整體上看側重模板化的封裝，而審批類的業務則傾向流程的配置化，每個審批場景從開始到結束，完成需要經過多個節點，節點之間又存在遞推或者回退的動作：
- 開始：發起方提交審批動作，訊息會按照配置流程進行節點通知；
- 節點：配置審批條件(自動或手動)和人員或角色，以及規則定義，例如序列或者並行，回退節點、失敗原因等；
- 結束：流程結束後觸發通知機制，對流程節點中涉及人員或者其他角色進行訊息通知；
在審批流程的管理中，除了涉及大量的規則配置，還需要管理複雜的狀態流轉，不同的狀態描述不同的結果，並根據狀態生成相應的事件和動作，從而實現流程開始和結束的完整性。
五、寫在最後
很多業務需求都是有規律可尋的，例如報表中的計算、表單中的欄位和結構、審批中的流程管理，將業務底層不變的規則進行抽象封裝，可以是模板化管理或者流程化配置，從而應用對容易變化的業務場景。