WCF + CQRS +推送通知

Question

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

我被告知使用CQRS模式。

为了举例，客户将连接到服务以执行获取产品列表和更新产品等操作。他们还可以执行诸如接受装运和拒绝装运之类的操作（这可能会导致首先执行此操作的客户之间的竞争）。只有一个客户可以“接受”货物或“拒绝”货物。

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

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

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

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

4. 我花了一个多星期的时间试图了解如何为客户实施通知服务，没有运气。我有design：design http://s16.postimage.org/aqakx6j9f/asdf.png

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

Answer 1

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

更具体地说：CQRS既不是应该应用的银弹，也不是整个应用程序中的总体架构风格。

当应用于单个且指定良好的有界上下文时，CQRS可以提供​​许多优势（参见Eric Evans的Domain Driven Design）。

您或您的团队应首先询问的问题：

• 我申请的有限上下文是什么？
• 对于每个BC：它基本上是CRUD还是需要更复杂和复杂的建模？
• 如果它是CRUD然后实现它
• 如果它很复杂那么问题已经解决了吗？是否需要重新发明轮子，或者我们是否可以使用成品解决方案（从概念上或甚至是一个软件）
• 如果我们需要自己构建，这个特定的BC是否提供了主要的商业价值，我们的实施是否具有竞争优势的潜力？ （请参阅域驱动设计中的“核心域”）
• 如果以上适用，那么研究各种建筑风格并选择最合适的。

长话短说：不要试图强调整个应用程序的风格。确定BC并为每种用途提供满足要求的最简单的解决方案。这很可能是CQRS，但对于您的应用程序中最多只有一个或两个BC。

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

Answer 2

1. 数据库不同步执行任务，它们使用根据数据库事务隔离级别规则进行交叉的事务。但他们确实更新了他们的指数作为交易的一部分，这是重要的部分。
2. 不，但它消除了单个编写器阻塞多个读者的问题，在这些读者中您拥有高度争用的资源，例如数据库表。例如。在我工作的系统中，爆炸数据从传感器插入，也作为为用户创建报告的一部分阅读。这是CQRS非常适合的地方。 CQRS的大多数实现都控制着它们的并发性问题，它实际上是一个很好的模型和DDD，其中你的并发是严重竞争的业务逻辑。然而，你得到了其他属性，比如没有堆栈或者没有信号功能和消息重新排序。
3. 你将有两个数据库;一个保存事件（如果您正在进行事件采购）/实体，另一个/多个其他视图，您希望与事件保持同步。
4. 你想要使用像MassTransit + SignalR这样的东西。创建一个读取模型（基本上是每个屏幕的 DTO ），订阅事件并通过SignalR-hub将通知推送到浏览器。