小编Con*_*enu的帖子

所以我试图找出 CQRS+ES 架构的一般用例背后的结构，我遇到的问题之一是聚合在事件存储中的表示方式。如果我们将事件划分为流，那么流究竟代表什么？在跟踪一系列项目的假设库存管理系统的上下文中，每个项目都有一个 ID、产品代码和位置，我无法可视化系统的布局。

从我在互联网上收集到的信息来看，它可以简洁地描述为“一个聚合一个流”。所以我会有一个 Inventory 聚合，一个包含 ItemAdded、ItemPulled、ItemRestocked 等事件的单个流，每个事件都带有包含项目 ID、更改数量、位置等的序列化数据。聚合根将包含一个 InventoryItem 对象的集合（每个都有它们各自的数量、产品代码、位置等）这似乎允许轻松执行域规则，但我看到了一个主要缺陷；将这些事件应用于聚合根时，您必须首先重建该 InventoryItem 集合。即使使用快照，对于大量项目，这似乎也非常低效。

另一种方法是让每个 InventoryItem 有一个流跟踪与仅项目有关的所有事件。每个流都以该项目的 ID 命名。这似乎是更简单的路线，但现在您将如何执行域规则，例如确保产品代码是唯一的，或者您不会将多个项目放入同一位置？看起来您现在必须引入 Read 模型，但将命令和查询分开难道不是重点吗？只是感觉不对。

所以我的问题是“哪个是正确的？” 部分两者？两者都不？像大多数事情一样，我学得越多，我就越知道我不知道......

我正在设计一个基于 .Net 核心的微服务系统。架构系统将如下图所示。

问题是：我在 Microsoft 的网站上阅读了有关 SignalR 的通知，需要集成 SignalR（实时）以获取通知。但我认为我应该把集线器（API 网关？，微服务？...）放在哪里？我如何为这个系统应用signalR。

谢谢。

我一直在学习实现微服务,但我无法理解术语"有界上下文"？

我可以理解它是由域驱动设计产生的概念.但我无法理解它的技术实现.

我看了下面的链接:

1. 微服务和有限的上下文
2. https://martinfowler.com/bliki/BoundedContext.html
3. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/microservice-domain-model

我有一个电子邮件草稿与以下命令的聚合根：addToRecipient，addCcRecipient，addBccRecipient，updateBodyText，uploadAttachment，removeAttachment并在UI我想禁用SEND按钮，如果还没有准备好要发送的草案（即至少有上收件人和正文中有文字）。我知道我不允许查询聚合，但这是唯一可以告诉我可以发送或不能发送电子邮件的消息。

如果我要应用我对事件源和CQRS的了解，则聚合将发出一个EmailIsReadyToBeSent事件，而我的UserEmailDrafts读取模型将选择该事件并以某种方式更新UI，但是，我将必须在每个命令之后检查并发送取消事件，即EmailIsNotReadyToBeSent。

这感觉很复杂，您怎么看？