仅用于更新投影的事件

发布于 01-09 13:24 字数 377 浏览 3 评论 0原文

我们在应用程序的一部分中引入了事件溯源和重构到丰富的域模型,但我们对其中的一部分有点困惑。

我们有 Tank,它们是聚合根,我们经常收到有关这些 ThankTankGauge 信息。由于历史计量信息与任何业务逻辑都不相关,因此聚合并不保存所有计量表的集合,它仅引用最新的计量表。

为了显示历史指标,我们确实设置了投影。

现在我们收到请求:我们想要更新历史指标的评论。唯一的相关性在于历史指标的预测。这会导致在聚合上应用 RemarkSetOnHistoricalGauge 事件基本上是无操作的情况,只有投影会相应更新。

这可行,但感觉有点违反直觉。对这种方法有什么建议吗?

We're introducing event sourcing and refactoring to a rich domain model in a part of our application and we're a little bit confused about a part.

We have Tanks, which are the aggregate root and we receive TankGauge information on those Thanks every so often. Since the historical gauging information is not relevant for any business logic, the aggregate doesn't hold a collection of all the gauges, it only has a reference to the most recent gauge.

To display the historical gauges, we do have a projection set up.

Now we're getting the request: we want to update remarks on a historical gauge. The only relevancy this has is on the projection that holds the historical gauges. This causes a situation in which applying the RemarkSetOnHistoricalGauge event on the aggregate is basically a no-op and only the projection will be updated accordingly.

This works but it feels counter a bit counter-intuitive. Any suggestions on this approach?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

英雄似剑2025-01-16 13:24:55

我会考虑这里是否有两个有界上下文:

  • 储罐计量上下文:使用 TankGauge 命令,验证它们是否有意义(如果没有,那么就没有必要使用 TankGauge 命令) 发出 TankGaugeWas (TankLevelWas?) 事件
  • >Tank 聚合)并在储罐历史上下文中 :允许备注/注释关于历史级别的制作

这两者都有坦克的概念,但不是同一个概念。历史上下文消耗来自测量上下文的事件(从历史上下文的角度来看,这些事件成为命令,隐式地“将此事件合并到您的世界观中”)。它们可以有不同的聚合逻辑:甚至可能值得将坦克历史聚合建模为时间窗口,例如明天的坦克与今天的同一个坦克不是相同的聚合(这具有您没有的主要好处)加载整个测量历史记录或扫描快照历史记录)。

这种能够实际涵盖不同上下文使用术语来表示不同事物的情况的能力是 DDD 的优势之一(并且该术语具有不同含义的事实是一个非常强烈的迹象,表明存在上下文边界被跨越) 。

I would consider whether you have two bounded contexts here:

  • the tank gauging context: consuming TankGauge commands, validating that they make sense (if you're not, then there's not really a point to having the Tank aggregate) and emitting a TankGaugeWas (TankLevelWas?) event
  • the tank history context: allowing remarks/annotations to be made regarding historical levels

Both of these have a concept of a tank, but not the same one. The history context consumes events from the gauging context (those events become commands, implicitly "incorporate this event into your worldview", from the perspective of the history context). They can have different aggregate logic: it might even be worth modeling a tank history aggregate as being time-windowed, e.g. that the tank tomorrow is not the same aggregate as the same tank today (this has the main benefit that you don't have to load the entire history of measures or scan through a history of snapshots).

This ability to actually cover the situation where different contexts are using a term to mean different things is one of the strengths of DDD (and the fact that the term takes on a different meaning is a very strong sign that there's a context boundary being crossed).

删除→记忆2025-01-16 13:24:55

捕捉外部世界发生的事件与使用事件重新水合聚合是正交的。事实上,聚合没有映射今天的事件只是偶然,它可能会随着时间的推移而改变。但捕捉事件是必要的。

顺便说一句,提出与聚合没有直接关系但对预测有价值的事件是正常的。

我过去也有类似的例子。我们的 Identity 域监听在 Email 子域中发布的事件,以针对发送的电子邮件引发自身内部的 EmailSentEmailDelivered 事件更早地提供给用户。如果用户继续使用网站,这些事件有时可能会不按顺序到达。聚合不包含表示此信息的属性,但此类事件有助于交叉检查注册和转化。

Capturing events as they happen in the external world is orthogonal to using the events to re-hydrate an aggregate. The fact that the aggregate does not map an event today is just happenstance, which could change over time. But capturing the event is a necessity.

As an aside, raising events that have no immediate relevance to the Aggregate but are valuable for projections is normal.

I have a similar example from my past. Our Identity domain listened to events published in the Email subdomain to raise EmailSent and EmailDelivered events within itself against emails sent earlier to a user. These events can sometimes arrive out of sequence if the user continues to use the website. The aggregate does not hold attributes to represent this information, but such events helped cross-check signups and conversions.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文