仅用于更新投影的事件
我们在应用程序的一部分中引入了事件溯源和重构到丰富的域模型,但我们对其中的一部分有点困惑。
我们有 Tank
,它们是聚合根,我们经常收到有关这些 Thank
的 TankGauge
信息。由于历史计量信息与任何业务逻辑都不相关,因此聚合并不保存所有计量表的集合,它仅引用最新的计量表。
为了显示历史指标,我们确实设置了投影。
现在我们收到请求:我们想要更新历史指标的评论。唯一的相关性在于历史指标的预测。这会导致在聚合上应用 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 Tank
s, which are the aggregate root and we receive TankGauge
information on those Thank
s 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 技术交流群。

发布评论
评论(2)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
我会考虑这里是否有两个有界上下文:
TankGauge
命令,验证它们是否有意义(如果没有,那么就没有必要使用TankGauge
命令) 发出TankGaugeWas
(TankLevelWas
?) 事件这两者都有坦克的概念,但不是同一个概念。历史上下文消耗来自测量上下文的事件(从历史上下文的角度来看,这些事件成为命令,隐式地“将此事件合并到您的世界观中”)。它们可以有不同的聚合逻辑:甚至可能值得将坦克历史聚合建模为时间窗口,例如明天的坦克与今天的同一个坦克不是相同的聚合(这具有您没有的主要好处)加载整个测量历史记录或扫描快照历史记录)。
这种能够实际涵盖不同上下文使用术语来表示不同事物的情况的能力是 DDD 的优势之一(并且该术语具有不同含义的事实是一个非常强烈的迹象,表明存在上下文边界被跨越) 。
I would consider whether you have two bounded contexts here:
TankGauge
commands, validating that they make sense (if you're not, then there's not really a point to having theTank
aggregate) and emitting aTankGaugeWas
(TankLevelWas
?) eventBoth 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).