构建审计跟踪功能

Question

以下是工作流程系统中的用例

• 工单进入系统。在完成工作单之前，工作订单将具有通过不同工作流程状态的目标。

• 说目标车辆的工作订单进入系统 - 此工作的工作流程涉及2个任务说

  a）洗车

  b）检查车辆

说清洗车辆工作流程任务将车辆属性从“未清洗”更改为“清洗”。并说“检查车辆”工作流程任务将车辆属性“未检查”改为“检查完成”

如果用户正在提取工作订单数据，用户将始终看到最新的车辆数据（在此示例中假设两个工作流程任务都已完成，用户将看到值“已清洗”和“已完成检查”。但是，当用户仅提取工作流程时，任务清洗车辆数据 - ＆gt;用户将看到“已清洗” - 第二个任务完成后，工作流任务1将只看到它已修改。获取工作流任务2的数据将同时看到“已清洗”和“已完成检查”

这涉及数据的milstoning（审计跟踪）;一种方法如下图所示 - 当工作流任务修改数据时，它将更新版本号，modified_ts并在其自己的数据行中维护该版本号（通过如下所示的JOIN表）。基本上这只是维护对工作流任务数据的历史记录的引用，因此在提取工作流任务数据时，它知道要撤回哪个历史记录。请忽略parent_id和其他注释，下图中的噪音。这与这个问题无关。

我认为事件采购也将是另一种替代设计 - 但是不希望将事件采购（或任何其他类似解决方案）作为整个销售解决方案应用，但仅针对此特定用例（仅影响3个左右的表）审计线索很重要）。我正在尝试评估CQRS /事件源是否适合作为部分解决方案（同样仅限于3-4个需要保留历史/审计跟踪数据的表）或ES / CQRS是否过度杀伤？还有其他想法吗？

P.S。虽然这与Scala无关 - Scala是我们正在使用的平台，因此标记它以查看是否有特定于语言的解决方案可以提供帮助。标记Akka以查明是否通过Akka持久性ES / CQRS是一种选择。 Postgresql是一个数据库 - 而数据库触发器不是我想要的解决方案。