建模作業執行流程的設計模式

Question

在我的應用程序中，我有一組要執行的作業。每項工作都經歷了「未開始」，「已開始」，「已完成」，「失敗」等狀態。每項工作都有一系列先決條件和後置條件。直到滿足前提條件才能開始工作，如果不符合崗位條件，則應將其標記爲失敗。

例如，假設作業將文本文件導入到數據庫中。前提條件是檢查源文件是否存在，並且發佈條件是檢查數據庫中是否存在數據。

除了這些事前和事後條件之外，有時一份工作也依賴其他工作來完成。創建作業表併爲作業創建依賴表很容易，但實際上可以使這些預驗證和驗證後驗證可在數據庫中進行配置（以便在這些條件發生變化時不需要更改代碼或新的條件被添加）？即使有可能，這樣做是個好主意嗎？

需要使此模型具有通用性，以便其他應用程序也可以使用它，即使對其他應用程序執行的驗證檢查完全不同。

Answer 1

我想你會冒着嘗試駕駛太多的風險。通過嘗試表驅動所有的前後驗證條件，您會越來越接近嘗試在數據中編寫代碼。

我已經構建了一些非常複雜的作業調度應用程序。特別值得關注的是每日ETL過程，該過程會根據平面文件源加載數十個SQL表。

現有系統使用線性過程，其中程序員必須手動計算表間相關性並按給定順序運行表加載。問題在於，如果有任何進程失敗，其餘的工作就不得不坐下來等待問題解決。

我構建了一個新的系統，它具有表驅動元數據，指出了直接的表間依賴關係。換句話說，表A對錶B和C具有FK。不是手動跟蹤全部的相互依賴關係，而是隻跟蹤直接的相互依賴關係。然後，調度程序只需查看哪些裝載已完成，哪些裝載尚未完成。任何沒有不完整依賴關係的未決加載可以開始。

我認爲你應該建立你的系統類似。使用關注點分離。不要驅動器什麼依賴關係是，而應該只是驅動器哪些依賴關係存在。您可以跟蹤調度表中哪些依賴項已通過，哪些已失敗。數據庫不需要知道如何做這些測試。讓代碼擔心什麼是依賴關係，以及如何測試它們是否通過或失敗。這是你所有的工作調度員需要知道的。避免創建源代碼位於數據庫中的腳本語言的誘惑。

Answer 2

考慮將應用程序與規則引擎（也稱爲業務規則）集成。這個想法是在代碼之外定義的邏輯，並存儲在一個表或文件中。規則引擎讀取規則並解釋。

這些軟件可以很快變得複雜。大多數情況下，它們都是商業軟件包，但存在一些免費和開放源代碼框架。我沒有使用任何免費軟件包。通常，我建議查看現有的代碼，而不是從頭開始構建規則引擎。

尼斯介紹由Martin Fowler： http://martinfowler.com/bliki/RulesEngine.html

多一點物質的文章： http://www.infoq.com/articles/Rule-Engines

要查找實際的代碼，谷歌的「規則引擎」或「工作流引擎」，並添加在您的編程語言的名稱（「Java」，「C＃」或什麼）。