以下是工作流系统中的一个用例
工单进入系统。工作订单将有一个目标，该目标在完成工作订单之前会经历不同的工作流程状态。
假设目标车辆的工作订单进入系统 - 此工作订单的工作流程涉及 2 个任务
a) 洗车
b) 检查车辆
假设清洗车辆工作流任务将车辆属性从“未清洗”更改为“已清洗”。并说“检查车辆”工作流任务将车辆属性“未检查”更改为“检查完成”
如果用户正在提取工作订单数据，用户将始终看到最新的车辆数据（在此示例中，假设两个工作流任务都已完成，用户将看到值“已清洗”和“检查完成”。但是，当用户仅提取工作流任务清洗车辆数据时 -> 用户将看到“已清洗”-虽然第二个任务已完成，但工作流任务 1 只会看到它已修改。获取工作流任务 2 的数据将同时看到“已清洗”和“检查完成”
这涉及数据的磨石（审计跟踪）；一种方法如下图所示 - 当工作流任务修改数据时，它将更新版本号、modified_ts 并在其自己的数据行中维护该版本号（通过如下所示的 JOIN 表）。基本上，这只不过是维护对工作流任务数据的历史记录的引用，因此在提取工作流任务数据时，它知道要拉回哪个历史记录。请忽略parent_id下图中的其他注意事项、噪音。这与这个问题无关。
我认为事件溯源也将是另一种替代设计 - 但是不想将事件溯源（或任何其他类似解决方案）作为一个整体销售解决方案应用，而仅适用于这个特定用例（仅影响 3 个左右的审计跟踪表事项）。我正在尝试评估 CQRS/事件溯源是否适合作为部分解决方案（再次仅限于需要保留历史记录/审计跟踪数据的 3-4 个表）或 ES/CQRS 是否会过大？还有其他想法吗？
PS 虽然这与 Scala 无关 - Scala 是我们正在使用的平台，因此对其进行标记以查看是否有特定于语言的解决方案可以提供帮助。标记 Akka 以通过 Akka 持久性找出 ES/CQRS 是否是一个选项。Postgresql 是一个数据库 - 而数据库触发器不是我正在寻找的解决方案。