我们尝试在项目中遵循SOA和DDD原则。我们使用NServicebus作为消息传递总线。 到目前为止，我们有20多项服务。
你们如何设置监控（我不是在谈论技术监控 - 就像服务“xyz”可达 - 是硬盘满了吗？）
例如
如果下订单并且5天后发货，但它应该在1天后执行......那是错误的情况。
或另一个例子： 运费完成。现在我们向客户发送电子发票。我们必须将该发票存档并与第三方（存档提供商）异步通话以检索我们的发票。如果5天后没有检索到该发票......那就是错误情况。
我在定义如何对错误是什么进行建模标准以及何时放置这些标准时遇到问题。
在哪里......
...你是否设置了监控规则？
监控规则是您有限上下文的一部分吗？我想是的。
监控规则是否与实体直接相关？我想不
监控规则是否与汇总直接相关？我想不是。
监控规则类似于跨多个聚合的域服务，但与域服务相反，也可以跨越多个有界上下文。
谁是责备人？
如何......
...你在代码中设置了监控规则吗？
如果你想要做到这一点，那就是非常努力。否则你可以做得很便宜（在这里和那里做一些查询）但这是针对SOA（我关注的主要部分）
请指导我一个清晰易用的解决方案。
我也很高兴知道你如何设置它。
答案 0 :(得分：2)
要识别的第一件事是您感兴趣的事件。您已经有一些示例，例如订单发货延迟，发票检索延迟等。从业务角度来看，这些事件具有特定的含义和具体后果。决定这些活动的标准应该与领域专家一起完成 - 他们应该能够说出这样的事情，例如，当订单在1天后没有发货时，应该发生＆＃34;。
这当然与实施此event-driven architecture不同。实现上述时间触发事件的一种方法是运行连续进程，该进程按计划运行查询。此查询将检索满足查询运行时事件条件的实体集。生成的系统将发布这些时间触发的事件。这些事件的NServiceBus处理程序会将事件的处理委托给域层。
关于何处，我同意这些事件的定义和处理通常与特定的有界背景相关联。然而，它们可以跨越多个BC，例如当来自一个BC的事件在另一个BC中处理时。就代码的物理位置而言，事件处理程序应该接近相应的域逻辑。例如，您可能有一个运输BC，要求在运输延迟时发送消息。在这种情况下，整个工作流程将包含在单个BC中，可以使用单个VS解决方案实现。
如上所述，这些事件的方式应该是基础设施的一部分。另一方面，事件的处理应委托给域层。例如，您可以拥有使用NServiceBus发布OrderShippingIsLate消息的基础结构。在运输BC解决方案中，您具有此消息类型的NServiceBus处理程序，该处理程序将调用处理此消息的应用程序服务（通过为支持代表添加任务，调度某种警告等）。 / p>
答案 1 :(得分：0)
我同意您的监控应该在域名服务中完成。阅读有关规范模式的this book以及如何实现它。他们的例子非常接近你的情景。