0

我正在学习工作流引擎 Camunda。我知道对于一些长期运行的流程，流程建模带来了许多战术和战略上的好处，例如表现力、容错性和可观察性，当然还有额外的开销。

我正在阅读的这本书还提倡使用 DMN（决策表）将业务规则捆绑在流程模型中。其动机是集中维护并将配置与代码分离。我对这个建议持保留态度，因为决策表听起来有点笨拙。没有强类型和强大的 IDE 功能。我习惯于将业务参数存储在数据库表中并由应用程序使用的实现。该实现还提供管理 GUI 以在运行时维护这些参数。

出于什么原因，我应该偏爱 DMN 而不是更可靠的基于数据库的解决方案？

4

1 回答 1

0

您正在将业务逻辑移至 BPMN 以将其从代码中取出，使其在图形模型中透明，可供所有利益相关者访问，支持业务与 IT 对齐，授权业务拥有他们的业务流程/逻辑，支持多版本制定运行时，以及更多...

同样的推理也适用于业务规则，因为它们过于复杂而无法在 BPMN 图中建模为图形。DMN 标准也针对商务人士，使用的表达语言有意保持比 Excel 公式简单。它是“足够友好的表达语言”（FEEL）。所以你知道这是怎么回事。

数据库表

  • 业务用户无法很好地访问
  • 不要在运行时灵活更改表结构/模式
  • 通常不支持运行时的多版本制定
  • 除非您使用多个表，否则不支持规则的图形逻辑分解（到 DRD） - 但 db 架构不灵活
  • 无法轻松部署到许多系统
  • 无法在单元测试中轻松测试
  • 可能不会自动生成可供审计和分析使用的审计数据

这些只是几点。因此，对于业务规则，绝对是 DMN over DB 表。

于 2022-02-24T05:45:22.293 回答