業務軟體複雜度管理

複雜度來源

• 業務主流程自身很複雜，而且很長。
• 流程被包裝成平台，被細分場景服用。導致一個步驟需要處理多種場景。
• 業務的多個側面需要同時被照顧到，比如在流程一個點上要同時處理流程狀態，計費需求，服務管控的需求，營銷需求，安全類需求。
• 底層基礎設施不好用，比如需要分庫分表。導致代碼里大量地在處理非功能性需求，淹沒了業務邏輯。

複雜度管理方式

• 減少代碼和業務人員mental model的gap
• 規範流程實現方式，多個單據串聯出複雜的流程
• 橫切領域的直接支持
• 運營配置的直接支持，並基於運營配置實現流程的定製化
• 內建的業務流程可追溯性，基於持久化的流程單據和變更日誌
• 對流量回放的直接支持，整體業務流程在新代碼下重跑

複雜度管理框架

有很多框架和庫來解決非功能性需求。但是卻沒有框架來幫助業務開發人員來對業務進行良好建模，來管理複雜度。django admin 已經比較類似了，但是偏底層。比較類似 orm + bpm，但是不需要那麼重的orm（單表做到極致，而不是支持複雜關聯），bpm也是業務代碼（比如php）控制流程，而不是bpm描述語言來控制流程。

• 業務實體和單據：orm without the bullshit
• 通用流程單據的CRUD，主要是屏蔽非功能性需求。保證一段流程，有自己的一個單據來對應。
• 流程單據的狀態變更自動觸發事件，事件可以根據配置喚起預定好的其他支線業務流程
• 業務實體的CRUD，主要是屏蔽非功能性需求。強調每個領域的業務，可以對實體進行自己的建模
• 實體之間可以有自動同步機制。類似sql里的create view的概念。可以把流程單據的計數等結果保存到實體的狀態上。
• 統一的運營管理界面（類似django admin）。對於流程單據和實體狀態提供直接的查看和管理功能。

• 配置（運營規則）：對一個流程單據該怎麼走流程的參數配置
• 統一的運營配置界面。只需配置就可以實現管理後台。代替各種業務配置文件（比如計費參數之類的）。配置直接配送到前台機器上，無需自己去緩存。

• 統一的 product/category 對應管理。運營規則只映射到category。方便product的添加
• 流程：bpm without the bullshit
• 流程銜接時，最終一致性的保障。比如訂單結束了，收款單必須創建成功。這個業務事務具有最終一致性。
• 橫切的業務需求可以以插件的方式插入到主流程中。如果能夠非同步集成的，就用事件的方式集成。
• 場景化的流程是現有流程步驟的組合。組合可以選擇在步驟中插入自己的擴展代碼。但是每個場景化流程具有邏輯和物理上的獨立性。
• 統一的運營配置界面。只需配置就可以實現管理後台。代替各種業務配置文件（比如計費參數之類的）。配置直接配送到前台機器上，無需自己去緩存。

如果有這樣一套典型的業務框架，可以多一種選擇。現在的公司要開闢新業務，都是從mvc這樣的底層開始搭起。重複造輪子不說，關鍵是造得不好啊。

推薦閱讀：