问题标签 [ncqrs]

在准备未来的应用程序设计时，我已经开始对 CQRS 风格的应用程序，尤其是Ncqrs进行一些调查。

虽然大多数概念都很清楚，但我对快照的概念有点困惑。

我可以理解为什么从对象的事件中重建对象可能会耗费大量资源，但是由于非规范化器将使用实体的最新状态（或者实际上是视图所需的最新值）来构建读取模型，所以为什么要打扰这个概念从快照重建对象？

我是否认为这种情况只是偶尔发生和按需发生，主要是在升级版本或调试之后？

如果不是，那么拍摄快照的好情况是什么？

作为设置测试的一部分，如何存储事件？

目前我正在通过发送如下命令来初始化应用程序状态：

我ICommandService.Execute()用来发送Given和When部分中的命令。

由于域可以拒绝命令，因此我不想依赖它们。我宁愿通过模拟这样的事件来设置我的应用程序状态：

如何将事件从事件存储中推Given送到事件存储中，以便在处理“时间”部分期间重播它们？

谢谢

丹尼斯

我有一个向业务层发送命令的分层应用程序（实际上，该应用程序是基于ncqrs 框架的，但我认为这里并不重要）。

命令如下所示：

这个类没有逻辑，只有数据。

我想让用户输入他们的用户名、电子邮件，并且我希望系统使用当前日期来构建命令。

什么是最好的：

1. 创建基于 RegisterUserCommand 的强类型视图，然后在将其发送到业务层之前注入日期和 APi 密钥？

2. 创建一个RegisterUserViewModel类，用这个类创建视图并根据视图输入创建命令对象？

我编写了以下代码（用于解决方案 n°2）：

这段代码正在工作......但我想知道我是否选择了正确的方式......

感谢您的建议

[编辑]由于日期时间似乎引起误解，我添加了另一个属性“ApiKey”，它也应该设置在服务器端，从 web 层（而不是从命令层）

[编辑 2]尝试 Erik 的建议并实施我想象的第一个解决方案：

...可以接受吗？

使用 Ncqrs，有没有办法重播曾经发生的每一个事件（所有聚合类型）并通过我的非规范化器提供这些事件，以便从头开始重新创建整个读取模型？

编辑：

我认为最好提供一个更具体的用例。我在 ASP.NET MVC 应用程序中构建它，并使用实体框架（代码优先）来处理读取模型。为了加快开发速度（并且因为我很懒），我想使用一个数据库初始化程序，一旦任何读取模型发生更改，它就会重新创建数据库模式。然后使用初始化程序的种子方法重新填充它们。

鉴于我有两个限界上下文：

1. Fleet Mgt - 基于简单 CRUD 的支持子域
2. 销售 - 这是我基于 CQRS 的核心领域

当车队管理中发生 CRUD 操作时，应发布反映该操作的事件：

• 飞机创造
• 飞机已更新
• 飞机已删除
• 等等

需要这些事件 a) 更新销售域中所需的各种索引表和 b) 提供统一的审计日志。

问题：有没有一种简单的方法来存储和发布这些事件（到InProcessEventBus，我在这里没有使用 NSB）而不通过AggregateRoot，在简单的 CRUD 上下文中我不需要。

有人评估过 NCQRS 和 JOliver 的 EventStore 吗？两者之间是否有显着优势，或者它们是否针对不同的受众？

我所看到的：

NCQRS 内置了对 NServiceBus 的支持。不确定受支持的 NSB 版本，但 NSB 的许可更改使这成为我项目的一个问题。不要以为我想永远被 NSB 2.1 困住。我可能会更多地关注 MassTransit 或 RSB。NCQRS 似乎也有相当多的“入门”帮助，对于像我这样的新手来说，这是值得赞赏的。

EventStore 似乎具有总线机制的挂钩，但没有内置实现（可能是错误的）。EventStore 似乎在 3.0 版本中有相当多的近期活动，但除了一些简短的代码示例和我发现的播客之外，似乎没有太多帮助，尤其是对初学者来说，除了筛选堆栈溢出或组。

如果有现有的比较，请指出我的方向。如果我上面的假设不正确，请纠正我。

采取标准注册流程：

1. 用户注册

2. 用户收到带有链接激活帐户的电子邮件

3. 用户激活帐户

我正在谈论的问题是：

• 当我们创建初始帐户时，我们会存储用户名、密码、电子邮件、激活密钥

• 当用户单击激活密钥链接时，我们使用 readmodel 验证密钥

• 然后我们触发传递用户名的 ActivateAccountCommand

我如何加载用户帐户以在域中激活它？

最初我想将新用户 Acount.Id 传递给 readmodel 但在 CommandExecutorBase 中没有访问权限（我知道） - 我们不保存这个：

我需要向管理员列表发送一封电子邮件，作为对从 UI 发送的命令的响应。需要通知的管理员是从针对读取模型的查询中检索出来的。

目前 - 根据我的理解，我只有一个选择：在发送命令之前收集所需的管理员并将他们（名称/电子邮件对）添加到命令中。

或者 - 从命令处理程序跨越到读取模型是否可以接受？感觉不对，但我真的没有看到任何其他方式这样做？

我们正在使用 DDD 和 CQRS（使用ncqrs框架）启动一个 Web 应用程序，在我们开始编写我们自己的基础设施类库之前，我想看看是否有任何可用的。

我认为至少可以在任何项目中使用一些用于写入文件系统、发送电子邮件等的基本接口和通用实现。

除了缺少事件溯源的一些好处之外，在没有事件溯源的情况下将现有架构适应 CQRS 是否还有其他缺点？

我正在开发大型应用程序，开发人员应该能够在接下来的几个月内将现有架构分离为命令和查询，但是在这个阶段要求他们也添加事件源将是资源配置的一个巨大问题看法。我是否因不包括事件溯源而亵渎神明？