DMN決策模型的不足之處 - brcommunity

banq發表於2022-03-08
模型Unity

業務規則引擎平臺除了支援DMN決策模型以外應該有哪些功能？
DMN和決策模型的缺點對業務敏捷性、生產力和程式設計師工作量有很大影響。在這次討論中，我確定了六個主要缺點：
 

缺點一、缺乏業務語義
如果你認為你可以在沒有結構化的業務詞彙和詞彙表的情況下完成任何嚴肅的規則工作，你就是在自欺欺人。
業務規則的中心思想是使非程式設計師可以訪問邏輯。如果不包含明確的業務語義，你怎麼能做到這一點？！
 

缺點二、缺乏對行為規則的支援
規則引擎需要支援非常健康的行為規則。
行為規則是可以被違反或破壞的規則，它們管理持續活動的行為，因此對人員、組織和業務活動至關重要。
非常粗略地，您可以將行為規則視為業務約束。
它們還對資料質量產生巨大影響。
DMN決策模型不支援行為規則。
 

缺點3. 缺少對閃光點的支援
閃光點是指行為規則有可能被違反或需要被評估的事件。
一般來說，每個行為業務規則至少會產生兩個閃光點（但通常不會超過4-5個）。
專門針對個別事件的行為業務規則確實存在，但它們只佔少數。
考慮示例：

行為商業規則：使用積分預訂的預訂者必須是俱樂部會員。


對於這條規則，有四個閃點，如下所示：
  1. 建立預定積分。
  2. 持有積分預訂的人被更改。
  3. 積分預訂的預訂者已經不再是俱樂部會員。
  4. 現有預訂將轉換為積分預訂。

除非對上述四個所有閃光點規則進行評估，否則一些違規行為會被遺漏，這種遺漏對服務質量和資料質量有直接的影響。
事實上，這種遺漏是造成服務和資料這兩個方面的質量缺陷的根本原因，在傳統方案中往往是相當隱蔽的。

由於DMN和決策模型不承認或支援行為規則或閃光點，使用DMN和決策模型的應用系統必須自己評估行為規則和處理閃光點。這造成了巨大的程式設計師工作量。
將這項工作交付到規則平臺上，將極大地提高生產力。
 
關於流程模型，DMN決策模型迫使建模者和軟體開發者明確指出何時評估所有規則。
規則平臺必須被告知何時評估規則。
對於許多決策問題，儘可能長時間地等待資料堆積往往才會產生最佳結果。
但是，你絕對不想等待很長時間以後才可以評估大多數行為規則，因為行為規則是一個實時的問題! 很明顯，這個世界越來越實時了。

有沒有想過為什麼遺留系統經常產生如此不一致的結果？
一個很大的原因是程式設計師在編碼和管理行為規則和閃光點。
對我來說，這不是一個建立商業系統的非常聰明的方法。它也不能很好地解決情感和人類的自由裁量權，這是另一個重要的實時問題。
 

缺點4. 缺少一個獨立的觀察者
那麼，對行為規則和閃光點的實時支援的解決方案是什麼？
關鍵是實時監控事件，獨立於所有程式。
為此，你需要一個我稱之為觀察者的東西，就像足球比賽中的裁判，只不過是自動的。
這個觀察者只對檢測違反行為和執行閃光點的行為規則感興趣。

觀察者提供什麼能力？
監控除流程之外的事件，以檢測閃光點。

根據這些閃光點來評估行為業務規則。
為了實現這一目標，規則平臺需要保持對狀態的持續、不間斷的認知--這是DMN和決策模型的另一個缺陷。
  

缺點5. 缺少對狀態的認識
DMN決策模型對狀態沒有認識。從來沒有一個觀察者跟蹤狀態。

觀察者必須全面瞭解正在發生的事情，因為有 100 個、1000 個或更多的事件幾乎同時發生在幾十個、100 個或更多的流程中，以及所有未建模的、臨時性的互動。試圖只用流程模型來同步事件是無望的--或者至少是無望的複雜。

狀態的問題實際上把我們帶到了上面討論的第一個缺點。
處理業務狀態的最好方法是支援業務語義（概念模型）。讓我們在這裡說得很清楚。我所說的 "狀態 "是指業務狀態--而不是軟體狀態。

DMN對流程模型的依賴巧妙地鼓勵了對業務的程式性看法，在這種看法中，業務解決方案和系統模型很容易被混淆。
例如，我認為你不應該在分析和指定規則時看到關於同步流程的討論，那是一個系統問題。但是你確實在 DMN 圈子裡看到了這樣的討論（經常性的、長時間的） 。
 

缺點6. 缺少對自然語言的支援
DMN 和決策模型沒有提供對規則的結構化自然語言表達的支援。它們就是不適合自然地納入決策表。

政策手冊、法律檔案、科學和工程檔案等通常不被表達為決策表。(有時，決策表可以以有用的方式進行改造，以達到實施的目的，但即使如此，也只是部分處理。那剩下的所有規則怎麼辦？程式設計師的工作量!

在這個你幾乎可以用谷歌搜尋任何東西的時代，缺乏自然語言支援[是根本不可能實現的。

相關文章