将“结果”与“状态”分开的好处是什么

假设您有一些自动化流程，这些流程通常会经历以下状态；预定-启动-验证-执行-完成

最重要的是，由于错误或明确的用户取消，这些过程可能会过早结束。

我的第一个冲动就是简单地将错误添加并取消到可能的状态值列表中，但是我想知道将结果与状态分开的（概念上的）优势（即使在我看来，有人可能会认为错误和取消也是与完成状态完全不同的状态）。

您分配给进程的状态应反映程序（或用户，如果您只是在可视化状态）将使用此信息。那么，您是否需要评估/显示进程的状态（只要它们正在运行且没有错误）？然后将结果与状态分开。如果您只需要进程结束时的状态，则不要分开。

您不应仅为了建模而建模任何东西。更好地检查您的要求。而且，如果您不确定以后可能需要什么，请为确定的需求选择最小，最简单的解决方案。如果只是“猜测”，那么在所有情况的90％中，您都会猜错，因此无论如何您以后都必须更改模型。

但是我想知道将结果与状态分离的（概念上的）优势（即使在我看来，有人可能会认为错误和取消状态与完成状态完全不同）。

与您的情况一样，在详细说明进度并确定故障点（在合理范围内）方面，这具有很大的优势。我认为混淆源于“状态”和“状态”这两个词-我们必须对这些词进行限定。因此，例如“任务状态”，即使不是很精确，因此我们可能要使用“任务执行状态”，但这是错误的，因为您已经有一个执行步骤。我们可以使用“任务处理状态”作为名称，并且“初始化-验证-执行-完成”的值非常合理。实际上，我们可以在列表中添加“已取消”。但是，“错误”不能回答以下问题：什么是“ 任务处理状态”很好。看起来“错误”是Completed的子状态。那么我们该怎么办？我们可以将Completed重命名为单击“完成”，然后我们可以将“错误完成”添加到列表中。因此，“ 任务处理状态”值的最终列表为：

• 发起了

• 已验证

• 执行中

• 取消，

• 完成了，

• 错误完成

编辑：现在上面的列表仍然需要一些工作。前四个项目中没有单词“ OK”。因此，如果最好匹配“ Completed OK”状态。另一件事是前4个项目没有“错误”-这是什么意思？当“执行”异常结束时会发生什么-这是否要求将新状态变为“执行错误”？此时，可能需要更多的输入和分析。