此流程管理器状态是否应保留？

Question

我正在开发一个基于事件的电动汽车充电站管理系统，该系统连接到多个充电站。在此域中，我为充电站提出了一个汇总，其中包括充电站的内部状态（是否已连接，其连接器的内部状态）。

我可以向工作站聚合发出的命令是：

• UnlockConnector，它发出StationConnectorUnlocked

• StopConnectorEnergyFlow，它发出StationConnectorEnergyFlowStopped

[并且我提出了另一个汇总，代表计费会话，即用户与计费站的连接器之间的交互。计费会话的创建与这些事件相关联，即，如果用户已将连接器解锁，则创建会话，如果连接器的能量流已停止，则计费会话已结束。

我添加了一个监听事件的流程管理器：

• StationConnectorUnlocked(stationID, connectorID)-> SessionCreated(new uuid())

• StationConnectorEnergyFlowStopped(stationID, connectorID)-> SessionFinished(id???)

对于第一个事件，创建会话非常简单。但是，对于后者，它必须知道正在进行的会话的sessionID发生在Connector(connectorID)的Station(stationID)上，以便它可以更新会话。

我不能在实现事件源系统时简单地实现GetSessionByConnectorID函数，而获得会话事件流的唯一方法是通过其ID，而不是通过其ConnectorID（因为我只在回水时才知道会话的ConnectorID），所以我看不到如何实现GetSessionByConnectorID函数。

因此，流程管理器具有一些内部内存状态（(stationID, connectorID) -> (sessionID)），以跟踪sessionID。但是，由于它在内存中，因此一旦流程管理器崩溃，我就失去了(stationID, connectorID) <-> (sessionID)之间的关联，并且我无法再正确地响应ConnectorEnergyFlowStopped事件。

我该如何处理？我应该保持流程管理器状态吗？我是否应该将其与流程管理器事件一起使用（这很尴尬，因为它与通用语言没有很好的关联，我在考虑SessionProcessManagerReceivedStationConnectorUnlockedEvent-尴尬级别）

编辑-新思想

我想到了其他事情，这将是删除内部流程管理器状态，并将(stationID, connectorID) <-> (sessionID)的关联放入Station聚合中。不幸的是，这意味着更高的耦合度（工作站必须知道会话的创建时间以及如何生成其ID），但是我认为它可能会更简单（因为工作站的事件得以保留）。因此，工作站将发出与会话相关的事件，其中包含sessionID：

• StationConnectorUnlocked(stationID, connectorID, sessionID)-> SessionCreated(sessionID)

• StationConnectorEnergyFlowStopped(stationID, connectorID, sessionID)-> SessionFinished(sessionID)

但是，即使只是会话的ID，将两者混合在一起似乎有点奇怪。

Answer 1

我可以看到很多解决此问题的方法，但是我对您的领域不熟悉，所以只在这里提出想法：

• 使用流程管理器。流程管理器处理长时间运行的流程，并且需要保留状态_by定义。消息驱动的流程管理器通常甚至不需要在消息之间运行，因此他们可以处理事件，发出命令并关闭直到下一条消息。或完成。据我了解，这是第一个问题。

• 对于每个会话，来自工作站的会话会话UUID。然后，工作站将知道会话ID，并且不需要流程管理器。

• 使用查询模型。使用您需要的所有信息来投影会话开始的事件。在能量流停止时进行查询，以查找给定站点和连接器的正在进行的会话，您甚至可能不需要用户ID。投影sessionClosed事件并删除读取的模型。

[如果可能，我会选择第二个。由于相关的复杂性，最后一个将是我的列表中的第二个，而流程管理器将是最后的选择。

Answer 2

对我来说，流程经理只是在这里遇到麻烦。不应从任何地方生成聚合，我认为您过于担心Station了解Session。

为什么不像session = station.unlockConnector(sessionId)这样的表达方式？除非Session是一个完全独立的BC，否则在AR上使用工厂方法来创建新的相关AR是非常普遍的。

此外，Session的生命周期似乎与Station密切相关。关闭连接器后，您能否负担得起最终的一致性？如果会话在连接器关闭的同时发生变异该怎么办？