Observer模式似乎非常适合于实体在一个项目中的情况，否则，如果存在微服务，则可以应用以下模式。
看起来你有一些实体可以相互分离，并且这些实体可以被认为是一个独立的微服务。如果是的话，那么我们可以尝试应用下面的微服务模式。

图案：Messaging

使用异步消息传递进行服务间通信。服务通过在消息传递通道上交换消息进行通信。异步通信有几种不同的样式：

• 请求/响应-服务向接收者发送请求消息，并期望立即收到回复消息
• 通知-发送者向接收者发送消息，但不期待回复，也不发送回复.
• 请求/异步响应-服务向接收者发送请求消息，并期望最终收到回复消息
• 发布/订阅-服务将消息发布给零个或多个收件人
• 发布/异步响应-服务将请求发布给一个或多个接收者，其中一些接收者会发回回复

图案：Saga

将跨多个服务的每个业务事务作为一个 Saga 来实现。saga是一系列本地事务。每个本地事务都更新数据库并发布消息或事件以触发saga中的下一个本地事务。如果本地事务由于违反业务规则而失败，则saga将执行一系列补偿事务，以撤消前面的本地事务所做的更改。

图案：Command Query Responsibility Segregation (CQRS)

定义视图数据库，该数据库是设计用于支持该查询的只读副本。应用程序通过订阅拥有数据的服务发布的域事件，使副本保持最新数据。

虽然我很欣赏@StepUp的回答，但它并不完全符合我的需要。应用程序已经使用了相当多的事件（或读取消息）。CQRS将是一个主要的重写，因为不需要审计状态变化，我看不到它有足够大的好处。 Saga 似乎很有趣，但由于这不是一个微服务上下文，它将是很多。
在考虑了很长时间之后，我意识到观察者只会颠倒对另一方的责任。我需要一些核心的东西。
解决方案将是Mediator模式。中介者（只有中介者）将知道哪个工作流依赖于其他工作流。工作流本身不需要知道这一点。由于状态机已经触发事件，我可以使用它们来调用中介者，中介者将知道该做什么。