C# 如何在SOADDD环境中以正确的方式实现监控？

我们在项目中尝试遵循SOA和DDD原则。我们使用NServicebus作为消息传递总线。 到目前为止，我们有20多项服务

你们是如何设置监控的（我不是说技术监控——比如服务“xyz”是否可以访问——硬盘是否已满）

例如

如果下订单后5天发货，但应在1天后执行。。。这是一个错误条件

或者另一个例子： 装运完成了。现在我们向客户发送电子发票。我们必须归档该发票，并与第三方（归档提供商）异步对话以检索发票。如果发票在5天后未检索到。。。这是一个错误条件

我在定义如何根据什么是错误以及将这些标准放在何处对标准进行建模时遇到了问题

哪里…

。。。您是否设置了监控规则

监控规则是您的受限上下文的一部分吗？我想是的。
监控规则是否与实体直接相关？我想没有。
监控规则是否与聚合直接相关？我想没有

监视规则类似于跨多个聚合的域服务，但与域服务相反，域服务也可以跨多个有界上下文

谁负责

如何…

。。。您是否在代码中设置监视规则

如果你想把它做好，那就需要付出很大的努力。否则，您可以非常便宜地完成它（在这里或那里进行一些查询），但这与SOA（我关心的主要部分）背道而驰

请引导我找到一个清晰且易于实施的解决方案

---

我也很高兴了解您是如何设置的。

首先要确定的是您感兴趣的事件集。您已经有了一些示例，例如订单发货延迟、发票检索延迟等。从业务角度来看，这些事件具有特定的含义和特定的后果。应该与领域专家一起确定这些事件的标准-他们应该能够说“当订单在1天之后没有发货时，应该发生这样的事情”

这当然不同于实现这一点。实现上述时间触发事件的一种方法是运行一个连续进程，该进程按计划运行查询。此查询将检索在运行查询时满足事件条件的实体集。结果系统将发布这些时间触发的事件。这些事件的NServiceBus处理程序将事件的处理委托给域层

关于where，我同意这些事件的定义和处理通常与特定的有界上下文相关。但是，它们可以跨越多个BC，例如当一个BC中的事件在另一个BC中处理时。至于代码的物理位置，事件处理程序应该靠近相应的域逻辑。例如，您可能有一个配送BC，要求在配送延迟时发送消息。在这种情况下，整个工作流将包含在单个BC中，可以使用单个VS解决方案来实现

---

这些事件的处理方式应该是上述基础设施的一部分。另一方面，事件的处理应该委托给域层。例如，您可以拥有使用NServiceBus发布

OrderShippingIsLate

消息的基础结构。在shipping BC解决方案中，您将有一个用于此消息类型的NServiceBus处理程序，它将调用处理此消息的应用程序服务（通过为支持代表添加任务、发送某种警告等）。

我同意您的监视应该在域服务中完成。阅读规范模式以及如何实现它。他们的示例与您的场景非常接近。

您似乎在谈论长寿命流程。你试过传奇吗？从您对问题的描述中，我可以看到应用程序中的传奇故事的好地方——“监控规则”。）sagas广泛应用于我们的服务领域。问题是：在哪里定义了监控规则。但ddd似乎并不把它们看作一个单独的单元来关注，而是把它们看作域内的一个硬需求构建。所以，是的，这似乎是答案，但一个更简单的解决方案将是非常尼彻//在edit1之前写的。