1、基於規則的決策的dmn
dmn是決策模型和表示法的縮寫。像bpmn和cmmn一樣，它由omg管理。dmn是這三個標準中最新的一個。版本1.0於2015年9月發佈。截止到2016年6月，1.1版本已經被採用，也就是我們在本書中提到的版本。
dmn意義上的決策意味着根據定義的邏輯(決策邏輯)從給定的事實(輸入)中獲得結果(輸出)。
與bpmn和cmmn不同，dmn與活動或過程無關。DMN以一種操作上類似的方式工作:決策可以由業務用戶建模，然後由決策引擎執行。與bpmn和cmmn的另一個相似之處是，dmn標準規範既包含對錶示法的書面描述，也包含基於xml的正式元模型。
dmn標準爲決策建模提供了不同的方法。最流行的方法是決策表。在決策表中，您必須定義確定結果所需的特定條件。這個定義必須在技術層面上是可理解的和可實現的——bpmn用戶將認識到它是如何與bpmn相對應的——這就是爲什麼我們使用一種叫做“足夠友好的表達語言”(FEEL)的正式語言。feel是dmn標準的一部分，我們將在以後的文章中介紹它。
通常，複雜的決定是由相對簡單的決定組成的。以後的文章中我們會描述的決策需求圖(DRDs)幫助我們將複雜的決策分解爲它們的組件，並使它們更清晰。
與bpmn和cmmn類似，當建模的決策由兼容的決策引擎執行時，dmn的值達到峯值。這有以下優點:
-
透明度:每個人都可以很容易地瞭解決策是如何制定的。這些知識不再埋在某些員工的腦袋裏，也不再埋在難以理解的應用程序源代碼中。
-
可跟蹤性:決策引擎可以自動記錄每個決策。可以追溯作出某些決定的原因。
靈活性:決策邏輯可以更容易地適應。它不需要伴隨冗長的培訓或文件而推出;它可以被部署。在這方面，dmn比bpmn稍好一些，因爲更改流程引擎執行的bpmn圖對於非程序員來說風險太大。(這可能很難理解——畢竟，添加、移動或刪除幾個符號有多難呢?沒錯，但技術流程只是整個應用程序體系結構的一部分，可能會受到小更改的意外後果的影響。dmn決策表也可能發生類似的情況，但結果更容易識別，而且與bpmn不同的是，符號背後沒有需要維護的技術屬性。因此，業務部門可以更容易地獨立於it設計或調整軟件解決方案。
活動和決策緊密地交織在業務流程中。BPMN 2.0版本在dmn的第一個版本之前四年就定義了業務規則任務。即使這樣，也假定在完成流程時，規則將作爲決策的一部分不斷進行評估。然而，決策管理這個術語在當時並不常見;我們談到的是業務規則管理，而業務規則管理解釋了BPMN中對該任務類型的描述。cmmn版本1.1引入了決策任務的概念，它在含義和建模上等同於bpmn的業務規則任務。
在下篇文章中，我們將研究如何通過這些任務類型將bpmn和cmmn與dmn結合起來。
本文會持續更新，歡迎關注，技術支持：盤古BPM