Design patterns 同步两个状态机

比如说，我正在构建一个业务流程管理应用程序。它有以下实体：问题和任务，作为一个问题与多个任务相互关联。任务和问题都有各自的状态，一个的状态可能会影响另一个的状态

例如，它们都有“取消”和“完成”状态。当我将问题状态更改为“已取消”时，其所有任务都应变为“已取消”。当我将所有任务的状态更改为“已完成”时，问题应自动变为“已完成”

---

假设两个实体都有相当多的状态，并且从一个状态到另一个状态的转换逻辑和状态的依赖关系可能会改变，那么是否有任何设计模式和/或最佳实践来处理这种情况？

突然想到的设计模式是一条“规则”；-）

或者，如果您愿意，也可以使用命令模式

换句话说，对于这种情况，我将创建一个数据库表，列出状态和可接受的转换，并将操作与每个转换关联（使用反射）

我发现这对于处理转换操作比更新状态匹配更复杂的情况非常有用

---

例如，在一个系统中，我们有一个工作流，其中请求文件必须通过几个委员会审查站，每个审查站都可以拒绝或将文件传递到下一阶段，再加上定制的副作用处理。委员会的组织、处理结构和处理动作在开发过程中发生了三次重大变化，在部署的第一年又发生了五次。

对于这类事情，我更喜欢观察者模式：在您给出的示例中，我让任务观察他们的问题，而问题观察他们的任务。当问题被标记为已取消时，任务将查看并标记自己已取消。当一项任务被标记为已完成时，问题会看到它，并检查其他任务是否已完成，等等。

这就是我们现在使用的服务—一种针对问题执行操作的服务。这是一种很好的工作流管理模式，但它并不能真正帮助以干净、透明和可维护的方式同步两个状态机。一个相当于“使状态相同”的操作不会起作用吗？我真的无法想象这样的操作。比方说，我有一个CancelIssueAction，它将问题的状态更新为“已取消”。如果我想使该问题的所有任务也被取消，我需要将其编码为CancelIssueAction，这不是很透明。我在想一些更通用的方法，如PropagateIssueState，将给定问题的所有操作设置为与问题相同的状态。然而，在实践中，我最有可能使用更具体的CancelIssueAction行为来预测副作用（例如通知正在执行操作的人操作已取消！）