如何实施在SOA DDD环境中监控正确的方式？
我们试图在我们的项目中遵循SOA和DDD原则。我们使用NServicebus作为消息总线。 到目前为止，我们有20多种服务。如何实施在SOA DDD环境中监控正确的方式？
你们如何设置监控（我不是在谈论技术监控 - 喜欢的是服务“XYZ”到达 - 是硬盘已满）？
例如
如果订单被放置和航运在5天后进行，但它应该在1天之后已执行......这是一个错误条件。
或者又如： 航运完成。现在我们发送电子发票给我们的客户。我们必须存档该发票并与第三方（归档提供商）异步对话以检索我们的发票。如果该发票在5天后没有被检索到...那是一个错误情况。
我有问题，定义如何对什么是错误的，并在那里把这些指标分析指标分析模型时。
WHERE ...
...你设置了监控规则？
监控规则是否是有界上下文的一部分？我想是的。
监测规则是否与实体直接相关？我想不是。
监测规则是否与聚合直接相关？我想不是。
监控规则是这样的跨越多个聚集，但相对于域名服务还可以跨越多个限界上下文域的服务。
谁负责？
如何...
...你在代码中设置了监控规则？
如果你想做到这一点，它是一个非常大的努力。否则，你可以做到这一点真的很便宜（请在这里和那里的一些疑问），但多数民众赞成对SOA（主要部分我担心）
请指引我一个明确的，易于实施的解决方案。
我也非常高兴能够学习如何设置它。
要确定的第一件事是您感兴趣的事件的一组事件。您已经有一些例子，例如订单装运迟到，发票检索晚了等等。从业务角度来看，这些事件具有特定的含义和特定的后果。决定这些事件的标准应该与领域专家一起完成 - 他们应该能够说出诸如“当订单在1天之后未发货等等事情应该发生”的事情。
这当然是实现这个event-driven architecture不同。实现上述时间触发事件的一种方法是运行一个连续的过程，该过程按计划运行查询。该查询将检索在查询运行时满足事件标准的一组实体。最终的系统会发布这些时间触发的事件。这些事件的NServiceBus处理程序会将事件的处理委托给域图层。
关于在哪里，我同意这些事件的定义和处理通常会绑定到特定的有界上下文。然而，他们可以跨越多个BC，例如当一个BC的事件在另一个BC处理时。就代码的物理位置而言，事件处理程序应该靠近相应的域逻辑。例如，您可能需要BC运输公司，并要求在运输延迟时分派消息。在这种情况下，整个工作流程将包含在单个BC中，可以使用单个VS解决方案实施。
这些事件应如何成为上述基础设施的一部分。另一方面，事件的处理应该委托给域层。例如，您可以拥有使用NServiceBus发布OrderShippingIsLate消息的基础结构。在BC运输解决方案中，您将拥有一个NServiceBus处理程序用于此消息类型，它将调用处理此消息的应用程序服务（通过为支持代表添加任务，调度某种警告等）。
好像你在谈论长寿命的过程。你有没有尝试传说？从您对问题的描述中，我可以在您的应用程序中看到传奇故事的好地方 - “监控规则”。 :) – masted
sagas用于我们服务的广泛领域。问题是：监控规则在哪里定义。但似乎ddd并不把它们视为一个单独的单元来关心，而是作为域内的一个硬性需求。所以是的，这似乎是答案，但更简单的解决方案将是更好。 //在edit1之前写入。 –