问题标签 [cqrs]

我正在使用 CQRS 样式模式（无事件源）我只是将我的读取和写入分成 2 个单独的应用程序边界。

目前，该应用程序适用于一个 SQL 2008 数据库。我想添加多个读取数据库来分配工作量，因为容量开始变高。

我需要 SQL 2008 中的解决方案，我可以在其中更新单个数据库，并将更改实时复制/传播到其他节点。这只需要单向传播，因为应用程序只会写入单个“主”数据库。

我已阅读有关点对点事务复制的信息。任何使用过它的人，更新子节点有多少延迟？

还有其他解决方案吗？

在我看来，CQRS（命令和查询职责分离）方法可能适合在 GAE 上实现强大且响应迅速的社交应用程序服务器，因为：

1. CQRS 不需要 SQL 数据库（GAE 不提供）
2. 它确实需要一个能够保存序列化对象的数据库，GAE 实际上确实提供了
3. 它需要事件队列，GAE 也提供了
4. 它支持非阻塞、异步、基于消息的架构，巧妙地解决了 GAE 对长时间运行事务的限制
5. 它被宣传为具有高度可扩展性，这毕竟是乐观主义者选择 GAE 的原因

问题是，我是一个生疏的 Java 程序员，对这个选择几乎没有经验，我非常感谢任何一起使用过这两者的人的任何评论，或者至少从使用另一个的经验中调查使用一个。

我认为我的主要问题是：

1. 对于新应用程序的早期阶段，CQRS 是否过于复杂？
2. 是否存在任何使它们无法匹配的陷阱，例如 GAE 的 Datastore 可能无法很好地匹配 CQRS 要求？
3. 任何人都可以推荐Axon或Jdon特别适合（或不适合）GAE 吗？
4. 我还应该问什么其他问题？

我一直在为一个使用 J Oliver 的 EventStore 和 mongo 作为持久层的新项目研究事件溯源，但遇到了一些问题：

1. 在尝试事件源之前，我的域一直保存到一个数据库中，并且我一直在使用 Udi 的域事件模式，这对我来说非常有效，NHibernate 管理工作单元。但是，我最终得到了一个可以影响多个聚合的工作单元，例如。

   我“结帐”我的购物篮聚合引发了一个事件，处理程序通过创建一个发票聚合来响应该事件，该发票聚合反过来引发一个事件（这只是一个示例）

   在这种情况下，我有一个改变两个聚合根的工作单元 - 在事件存储中，我可以将引发的事件添加到两个不同的事件流中，但它们不会以原子方式持久化（第一个可能成功，第二个失败） . 那么人们怎么做才能避免这种情况发生呢？

2. 在github主页上，它建议您可以使用流畅的界面来配置EventStore，但是当我下载源代码时，编译它并在示例中查看wireup类似乎不可用 - 它是否在不同的分支中? （我有师傅）

3. 处理 IStoreEvents impl 的推荐方法是什么？作为类似于 Nhibernates 会话工厂的单例？

我是 CQRS 的新手，我想了解写入端（域）内的业务规则验证。我知道客户端验证应该根据有效日期（必填字段、字符串长度、有效电子邮件等）进行，业务规则/业务域相关验证应该在域端进行。实际上，同样的客户端验证规则也应该应用于域中的命令，因为我们不信任用户。

因此，我们有一个有效的命令 (AddEmailToCustomer)，并且在该命令上调用了命令处理程序。这是我的验证方法。

1. 在命令处理程序中创建两个命令验证器的实例。
2. 第一个验证与客户端验证相同的命令数据（必填字段、有效电子邮件等）
3. 第二个验证器根据第二个验证器内的逻辑验证数据。诸如“此客户是否活跃”之类的东西，或者其他什么。我知道不断变化的电子邮件不适合这里，但这并不重要。重要的是这里有一个业务验证。
4. 我们查看 Validator.Validate(ICommand cmd) 返回的 ValidationResult 发现有错误
5. 我们不会让存储库中的客户调用 AR 上的 UpdateEmail 方法。那么此时我们该怎么做呢？

我是否在命令处理程序中抛出异常并在那里添加这些错误？我是否将命令发送到错误队列或其他地方？我是否会回复 Bus.Reply 之类的内容并返回错误代码？如果是这样，我该如何处理错误消息？如何将这些错误传达给用户？我知道我可以稍后通过电子邮件发送给他们，但在 Web 场景中，我可以在命令中发送请求 ID（或使用消息 ID），并使用请求 ID 轮询响应并向用户显示错误消息。

感谢您的指导。

谢谢

使用 NEventStore 时如何集成到 NServiceBus 中？

我是 NSB ans ES 的新手，并试图在使用 ES 和 CQRS 时找出 NSB 的最佳设置。

我以与示例中的 DispatchCommit 相同的方式连接到 NSB， https://github.com/joliver/EventStore/blob/master/doc/EventStore.Example/MainProgram.cs

1. 你发布整个 Commit 或 Commit.Events 吗？
2. 您是否因为 NSB 在您的消息上需要 IMessage 而围绕您的消息创建一个包装器？那么你如何发布到正确的队列呢？因为 wrapper 与 OrderSubmittedEvent 相比是通用的，例如。如果可能的话，我不希望我的事件依赖于 NSB，因为我的域中也有它。

一些代码或指导非常感谢。

我们目前正在评估 CQRS 和事件溯源架构。我试图了解使用这种设计的维护含义是什么。我正在努力寻找答案的两个问题是：

1) 如果在应用程序启动并运行了一段时间后，需要向 ReadModel 数据库上的 ViewModel 添加额外字段，会发生什么情况？比如说，在 CustomerList ViewModel 上需要客户邮政编码，而以前不需要。因此，可以轻松地将额外的列添加到 ViewModel 数据库中，但是如何填充呢？据我所知，唯一的方法是清除读取数据库，并从头开始重播所有事件以备份 ReadModel 数据库。但是，如果应用程序已经启动并运行了数月或数年（正如我们希望的那样）怎么办。这可能是要重播的数百万个事件，只是为邮政编码列添加数据。

如果出于某种技术原因，ReadModel 数据库不同步，或者我们想要添加一个新的 ReadModel 数据库，我也有同样的担忧。似乎应用程序越旧，使用得越多，获得最新的 readmodel 就越困难和昂贵。还是我在某个地方错过了一个技巧？ReadModel 快照之类的东西？

2) 如果在重播所有数百万个事件以备份读取数据库之后，一些数据与预期不符（即看起来错误），会发生什么情况。人们认为，可能是事件存储中的某个错误或非规范化例程可能导致了这种情况（似乎如果在编码中可以依赖一件事，那就是错误）。如何去调试这个！这似乎是一项不可能完成的任务。或者，也许，我又错过了一个窍门。

我很想听听任何已经运行这样的系统一段时间的人的意见，维护和升级路径是如何为您解决的。

感谢您的任何时间和投入。

CQRS 很有意义。然而，它似乎与使用提供变更跟踪的 ORM 的方法互斥。如果我有一个“通道”用于查询以将我的对象作为 RO，则无需跟踪任何更改。如果我有另一个 CUD+ 命令通道，它更像是一种带有轻型 DTO 的 RPC 方法，然后发送自跟踪实体以在较低层合并。

如何协调这两种方法（CQRS / ORM + STE）？

我如何通过自己的服务总线构建？我知道有很多可用的开源服务总线，如 NService Bus、Rhino Bus 等......但我想通过这样做来学习......

1）你将如何建造巴士？它有什么特点

2）我怎样才能使它独立于队列技术..即它应该与 MSMQ 作为天蓝色队列一起使用（从未与天蓝色队列一起使用）

3）我如何实现监听器？我有一个链接.. Nservice Bus 是怎么做的 （MSMQListner）

4）我如何激活队列..我可以在 IIS 中托管我的服务，这样处理负载就不会成为问题（我希望如此）

5) MSMQ 的主机选项将如何？

请我不想使用 WCF。只是因为它使消息传递架构成为 RPC 调用

我在看 2 个场景：A 没问题，B 不确定。

场景 A：在提交后、分派前模拟应用程序重启

1. 启动 EventStore
2. 提交更改
3. 事件未发送
4. 停止事件商店
5. 启动活动商店

在第 5 步中再次发送提交的事件。这工作正常，我在调度程序代码中也看到了这一点。

场景 B：模拟总线错误

1. 启动 EventStore
2. 提交更改 1
3. 调度程序中的异常
4. 提交更改 2
5. 发货好

在这种情况下，我找不到该行为，并且想知道它是否是一个有效的案例：只有在总线代码中存在错误时才会发生这种情况。

是否存在将重试调度的触发器，或者我是否需要编写代码来处理这个问题，或者我的推理有问题？

我正在尝试在我的新项目中使用 CQRS 和 EventSorcing。我遵循 Greg Young 几年前建议的方式（Mark Nijhof 实施 - http://cre8ivethought.com/blog/2009/11/12/cqrs--la-greg-young/）。我有一些关于这个解决方案的可扩展性的问题。

这篇文章中提到了一些点Mark Nijhof 的文章。但现在的问题是 Denormalizer 部分，它负责更新报告数据库。这部分我想做异步，所以在将事件发布到总线后我想立即返回控制。我们建议可以将 Denormalizer 实现为独立的 Web 服务 (WCF)，它将处理传入事件并使用批量命令以定时方式更新报告数据库。看起来它可能是一个瓶颈，所以我们还想在这一点上添加一些可扩展性 - 一个集群解决方案。但是在集群的情况下，我们无法控制报告数据库更新的顺序（或者我们应该实现一些奇怪的，我猜有错误的逻辑会检查报告数据库中的对象版本）。另一个问题是解决方案的可持续性：如果失败，我们将在非规范化器中丢失更新，只要我们不在任何地方持久化它们）。所以现在我正在寻找这个问题的解决方案（Denormalizer 可扩展性），欢迎提出任何想法！