1

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

你们如何设置监控（我不是在谈论技术监控——比如服务“xyz”是否可达——硬盘是否已满）？

例如

如果下订单并在 5 天后完成发货，但它应该在 1 天后执行......这是一个错误情况。

或者另一个例子：运输完成。现在我们向客户发送电子发票。我们必须存档该发票并与第三方（存档提供商）异步交谈以检索我们的发票。如果 5 天后仍未检索到该发票……那就是错误情况。

在定义如何对错误的标准和放置这些标准的位置进行建模时，我遇到了问题。

在哪里 ...

...您是否设置了监控规则？

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

监控规则就像跨多个聚合的域服务，但与域服务相反，它也可以跨多个有界上下文。

谁负责？

如何 ...

...您是否在代码中设置了监控规则？

如果你想把它做对，它真的需要付出很大的努力。否则，您可以非常便宜地做到这一点（在这里和那里进行一些查询），但那是针对 SOA 的（我关心的主要部分）

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

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

4

2 回答 2

2

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

这当然不同于实现这种事件驱动的架构。实现上述时间触发事件的一种方法是运行一个按计划运行查询的连续过程。此查询将检索在运行查询时满足事件标准的实体集。生成的系统将发布这些时间触发事件。这些事件的 NServiceBus 处理程序会将事件的处理委托给领域层。

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

这些事件的方式应该是上述基础设施的一部分。另一方面，事件的处理应该委托给领域层。例如，您可以拥有OrderShippingIsLate使用 NServiceBus 发布消息的基础设施。在运输 BC 解决方案中，您将拥有此消息类型的 NServiceBus 处理程序，它将调用处理此消息的应用程序服务（通过为支持代表添加任务、发送某种警告等）。

于 2012-12-17T20:00:12.867 回答
0

我同意您的监控应该在域服务中完成。阅读这本书，了解规范模式以及如何实现它。他们的例子非常接近你的场景。

于 2012-12-18T18:00:21.957 回答