WCF + CQRS + 推送通知

Question

我必须设计一个连接到 WCF 服务的客户端系统，以对数据库执行读写操作，并获得通知。

有人告诉我使用 CQRS 模式。

举个例子，客户端将连接到服务以执行获取产品列表和更新产品等操作。他们还可以执行 Accept Shipment 和 Reject Shipment 之类的操作（这可能会导致首先执行此操作的客户之间发生竞争）。只有一个客户可以“接受”货件或“拒绝”货件。

所以我阅读了一些关于 CQRS 的内容，并理解它将读取与写入分离（使用命令）。但是，如果我使用 CQRS，我不确定一些主要问题：

1. 如果我在 WCF 服务上使用 CQRS 模式 - 我可以指望在数据库上同步完成的事情吗？我有点困惑，因为我不希望服务是单线程的（以支持未来的可扩展性），但另一方面 - 我如何确保服务上的写操作以正确的顺序执行？甚至读操作？ CQRS 模式是否保证有序处理？ （有人告诉我here CQRS 模式使用“更新”队列来更新离线处理请求）。

2. 使用 CQRS 能消除并发问题吗？

3. 我是否仍应在与数据库交互的所有命令处理程序中使用“TransactionScope”？

4. 我花了一个多星期的时间试图了解如何为客户实施通知服务，但没有成功。我有这个design：

“产品服务”将是 CQRS 服务，但通知服务有问题。客户端可以向产品服务发送命令以通知 X 类产品。该命令将更新数据库中的请求。现在假设通知服务每 15 分钟轮询一次数据库，并检查哪个用户希望轮询哪个类别，然后将新产品发送给请求就这些产品类别进行通知的用户。 如果用户更改了产品的类别并且其他 20 位用户已经在他们的通知窗口中看到了该产品，现在会发生什么情况？ 我需要一些方法来检测产品不再属于该类别，并向他们发送通知，例如 '从您的视图中删除该产品'。 这听起来不太像通知。这听起来更像是“请求一个数据库表的 CONSTANT RELEVANT 视图，并且每个更改都应该反映到客户端的屏幕上”。 这种通知服务怎么做？？

Answer 1

1. 数据库不同步做事，它们使用根据数据库事务隔离级别规则交错的事务。但他们确实会在交易过程中更新他们的索引，这才是最重要的部分。
2. 不，它没有，但它消除了单个写入器阻塞多个读取器的问题，其中您具有高度竞争的资源，例如数据库表。例如。在我工作的一个系统中，爆炸数据是从传感器插入的，并且作为为用户创建报告的一部分读取。这是 CQRS 非常适合的位置。 CQRS 的大多数实现都控制了它们的并发问题，实际上它与 DDD 一起是一个很好的模型，其中您的并发是严重竞争的业务逻辑。但是，您会获得其他属性，例如没有堆栈或因幂等性和消息重新排序而不得不死。
3. 您将拥有两个数据库；一个保存事件（如果您正在进行事件溯源）/实体，另一个/多个其他每个视图，您希望与事件保持同步。
4. 您可能希望使用 MassTransit + SignalR 之类的工具。创建一个订阅事件并通过 SignalR-hub 向浏览器推送通知的读取模型（基本上是一个每个屏幕的 DTO）。

Answer 2

这可能无法回答您的具体问题，但可能有助于评估您是否、为什么以及在您的应用程序的哪些部分可以（或应该）使用 CQRS？

更具体地说：CQRS 既不是无论如何都应该应用的灵丹妙药，也不是贯穿整个应用程序的总体架构风格。

将 CQRS 应用于单一且明确指定的有界上下文时，可以提供许多优势（请参阅 Eric Evans 的领域驱动设计）。

您或您的团队应首先提出的问题：

• 我的应用程序的限界上下文是什么？
• 对于每个 BC：它基本上是 CRUD 还是需要更复杂和精密的建模？
• 如果它是 CRUD，那么就这样实现它
• 如果它很复杂，那么问题已经解决了吗？是否需要重新发明轮子，或者我们可以只使用一个完成的解决方案（从概念上讲，甚至是一个软件）
• 如果我们需要自己构建它，这个特定的 BC 是否提供了主要的业务价值，我们的实施是否提供了潜在的竞争优势？ （参考领域驱动设计中的“核心领域”）
• 如果上述情况适用，请研究各种架构风格并选择最合适的。

长话短说：不要试图在整个应用程序上强加一种样式。识别 BC，并为每个 BC 使用满足要求的最简单的解决方案。这很可能是 CQRS，但您的应用程序中最多只有一两个 BC。

将精力集中在应用程序中最复杂的部分并且如果使用 CQRS 进行形式化和实施，则可以提供真正的优势。