我正在构建一个遵循 DDD 模式的应用程序，每个 AR 都将其事件发件箱保存到永久商店。该商店被对事件感兴趣的其他部分轮询。
整个应用程序是面向用户的，所以基本的基础设施是 asp.net web api。
现在，我想避免让我的域工件分布在不同的流程/基础设施选项中。例如，监听事件存储并在收到事件时执行逻辑的 Azure 函数。
将 Web api 和事件消费者放在同一个容器中似乎很方便。原因是域工件与 api 和事件消费者基础设施一起部署。
我读到这IHostedService可能是它的一种选择，因为它可以运行长时间运行的后台进程。
问题是，是否IHostedService适用于对事件发件箱做出反应的这种特定场景？还是我缺少一些重要的缺点和更好的基础设施选择？
这是一个链接。）关于实现 IHostedService。
实际上，IHostedService 是通过两种方法为您的方案长时间运行进程的好方法。请务必注意，部署 ASP.NET Core WebHost 或 .NET 主机的方式可能会影响最终解决方案。例如，如果您将 WebHost 部署在 IIS 或常规 Azure App Service 上，您的主机可能会因为应用程序池回收而关闭。但是，如果您将主机作为容器部署到 Kubernetes 等编排器中，您可以控制主机的活动实例的确定数量。此外，您可以考虑专门为这些场景设计的云中的其他方法，例如 Azure Functions。最后，如果您需要该服务始终运行并部署在 Windows Server 上，您可以使用 Windows 服务。
但即使对于部署到应用程序池中的 WebHost，仍然存在诸如重新填充或刷新应用程序的内存缓存之类的方案。
IHostedService 接口提供了一种在 ASP.NET Core Web 应用程序（在 .NET Core 2.0 和更高版本中）或在任何进程/主机（从 .NET Core 2.1 和 IHost 开始）中启动后台任务的便捷方式。它的主要好处是您有机会在主机本身关闭时通过优雅的取消来清理后台任务的代码。
一般来说，我认为使用托管服务来运行后台工作人员没有任何问题。
我对“来自其他有界上下文的轮询”部分持怀疑态度。我至少会担心这是否会破坏我的上下文的封装（类似于从上下文持久性中读取“外部”组件）。但在您的情况下可能并非如此。
无论如何，如果您只想保证您的事件被可靠地传输，我宁愿确保实现特定有界上下文的每个组件（例如微服务或单体组件）将这些事件推送到感兴趣的消费者能够接收它们的地方。
因此，如果是关于传出事件的可靠传输，我建议使用事务性发件箱模式，也许可以结合发布-订阅方法。
当您在 .net 堆栈上时，NServiceBus 的发件箱功能可能对您来说很有趣。