问题标签 [commanded]

在以战术域驱动设计为模型的事件源系统中，我无法处理以下情况：

1. 项目被选择在发票上。
2. 要么所有选定的项目形成发票，或者如果任何选定的项目无法分配，则不分配任何项目并且发票不存在。
3. 不变性：一个项目不得出现在多张发票上。
4. 一旦包含项目的发票存在，项目应转换为价格。

我的计划是

• 发票聚合类型，因此发票有一个标识来分组项目并存储计算的价格。
• 我会有一个 Item 聚合类型，它通过为每个聚合实例存储对一张发票的单个引用来跟踪不变量。

我想我需要针对新的 Invoice 聚合触发命令，其中包含要分配给新发票的现有项目 ID 的列表。这将发出一个关于发票创建的事件。

然后一些东西会监听这个事件并将它翻译成一个命令列表，这些命令将每个选定的项目分配给新发票。

我看到这可能会失败：例如，在发出命令后，其中一个选定的项目可能已分配给另一张发票。因此，我会以某种方式需要回滚所有未失败的分配并声明发票不再存在。

另一方面，要计算发票上的价格，我需要知道最初选择的所有项目何时实际分配给发票，以确保发票留在这里。

目前我正在使用 Elixir 中的 Commanded CQRS/Event Sourcing 框架，该框架基于 Erlang Actor 模型。

我的天真的想法来自于使用非分布式关系数据库的悠久历史，将整个情况放入一个同步事务中，该事务分布在两个聚合上。但是该框架似乎不支持这一点，它也或多或少地破坏了异步分布式聚合实现最终一致性的想法。

因此，我正在为我的问题寻找合适的解决方案。任何帮助，将不胜感激。

Commanded.ProcessManagers.ProcessManager在使用事件溯源/CQRS 框架 Commanded 中的模块实现 saga 模式时，我遇到了一个问题。

在发票上下文中，我需要为发票实施批量创建机制。这种大规模的创造既是一个聚合体，也是一个传奇。聚合允许开始和完成批量创建。saga 通过发出命令来创建发票并将它们的 ID 保持在 saga 状态来对“mass creation started”事件做出反应。之后，saga 通过监听它命令存在的发票实例的成功或失败事件来跟踪发票创建的状态。一旦每个发票实例报告成功或失败，saga 应该发出命令停止大规模创建。

为此，跟踪每个发票实例及其当前状态会很有帮助in progress：created或failed。我尝试在apply回调中实现这一点，原则上效果很好。

现在的问题是，apply回调总是在handle回调之后调用。因此 saga 状态会在 saga 应该做出反应之后更新。这似乎违反直觉，因此，handle回调中可用的状态不能用于正确反应。

在我看来，saga 模式在很多方面都是聚合模式的反转。虽然首先将命令处理成域事件然后将此域事件应用于状态以在聚合的情况下很有用，但我认为在 saga 的情况下，域事件是已经发生的事情的文档, 应该在尝试对其做出反应之前应用于状态。

现在我的问题是：有没有办法先配置 Commandedapply再handle配置Commanded.ProcessManagers.ProcessManager模块？或者这实际上是一个错误并且需要一般修复？

在使用 Commanded 和 Phoenix 构建的事件源应用程序中，我们consistency_timeout在部署到生产环境 (Heroku) 后的命令处理过程中得到一个。

这是日志输出：

如果我两次提交表单，其中一个命令会成功处理 - 但读取模型仍未更新。几分钟后，问题在生产中消失了。在我的机器上，问题似乎并没有消失。

该应用程序使用带有 Ecto 投影的 commanded 事件存储。

版本：

• 命令 0.17.0
• commanded_ecto_projections 0.7.1
• commanded_eventstore_adapter 0.4.0
• 事件存储 0.14.0
• 二郎20.3.2
• 灵丹妙药 1.6.5
• 凤凰 1.3.4

在 Elixir 1.7.4 上使用 Commanded 0.17.2 构建的应用程序经常耗尽内存。一项调查发现，内存泄漏似乎是由越来越多的聚合实例引起的，这些实例从未停止过。

有问题的聚合接收由外部系统触发的命令。在某些情况下，该execute函数会返回一个事件，而在其他一些情况下，该命令应该被忽略并因此返回nil（如docs所述）。

似乎每次nil返回而不是事件，聚合实例都无限期地保持活动状态。即使附加了超时和寿命，也会发生这种情况，这明确意味着其他事情：

我怀疑这是Commanded中的错误：

避免内存泄漏的一种方法是产生一个事件，即使没有人需要它。这将导致污染的持久事件存储而不是易失性内存，因此从长远来看可能会导致更大的问题。

我现在正在寻找一种方法来停止聚合实例，以防execute函数返回nil. 解决方法的每一个想法将不胜感激。

Event Store的作者 Greg Young不久前定义了关联 ID 来引用根本原因，而因果 ID 来引用消息的直接原因。

因此，您应该能够通过另一条消息的因果 ID 找到另一条消息直接响应的一条消息。并且您应该能够通过具有相同因果 ID 的消息在同一对话中找到所有消息。

如果应用此模式，则对话中的第二条消息应将相关 ID 和因果 ID 都设置为第一条消息。

在 Commanded 中，我希望第一个事件同时具有相关 ID 和因果 ID，以指向导致事件发生的命令（也可以在此处直观地描述）。

令人困惑的是，在 Commanded 自己的事件存储中，命令之后的第一个事件似乎具有不同的相关性和因果关系 ID。因此，Commanded 似乎不适用于 Greg Young 的定义。

我的问题是，Commanded 中这些 ID 的具体定义是什么？不遵循 Greg Young 的定义是有意识的决定吗？如果是，为什么？

是否会将这些版本信息放入事件的元数据中，或者是否已经建立了最佳实践？如果没有必要，不想重新发明轮子。