cqrs,eventurcing,元数据在哪里?

发布于 2025-01-25 15:05:04 字数 191 浏览 3 评论 0原文

如果一个骨料是“元数据驱动”的,并且需要将这种元数据与其他聚集体的元数据一起进行管理,是否是这种抗模式?

例如,有用于产品,用户,操作等的元数据,因此产品类型,用户组或操作类型不会被硬编码。还有一个元数据微服务可以管理所有元数据(大量版本的数据)。

产品微服务应如何获得命令验证之类的元数据?

关于如何在轴突中建模的任何建议?

If an aggregate is "metadata driven", and such metadata needs to be managed centrally together with metadata of other aggregates, is this anti pattern?

For instance, there are metadata for product, user, action etc so product type, user group or action type don't get hardcoded. There is also a single metadata microservice that manages all metadata (large amount of versioned data).

How should a product microservice get its metadata for things like command validation?

Any suggestions on how to model this in Axon?

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

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

发布评论

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

评论(1

浮华 2025-02-01 15:05:04

我并不是太确信只为元数据管理构建单独的服务是有道理的。再说一次,我不是全世界的领域专家,因此我可能会完全摆脱这一假设。

我觉得,如果您还谈论要使它成为中央服务,则使用术语元数据声音过载。也许还有另一个术语更有意义?

无论如何,我认为知道Axon框架支持每种类型的消息的元数据概念很有价值。因此,命令,事件和查询将始终携带元数据对象。说实话,这个元数据只是MAP of 字符串 to ?,哪个可以存储任何元数据有。

在大多数情况下,这包括userIdtraceidcorrelationId,某种形式的安全信息等字段。此外,据我所知,在大多数情况下,这不包括Product> Product Typepes等一流的公民数据。

回到您最初的问题:

如果一个骨料是“元数据驱动的”,则需要将这种元数据与其他聚集体的元数据进行管理,这是这种抗模式吗?

我不能肯定地说是建模用于管理所有元数据的服务是一种反图案。但是,对我来说,这确实是不必要的复杂性。请务必使用更多信息更新您的问题,以阐明您的想法,bing。完成此操作后,我一定会更新我的回复。

I am not overly convinced it makes sense to construct a separate service just for MetaData management. Then again, I am not a domain expert of the entire world, so I might be completely off with that assumption.

I feel that using the term MetaData sounds overloaded if you're also speaking about making it a central service. Maybe there's another term that makes more sense?

At any rate, I think it's valuable to know that Axon Framework supports the notion of MetaData for every type of message. Hence, Commands, Events, and Queries will always carry a MetaData object. This MetaData is, in all honesty, just a Map of String to ?, which can store whatever metadata you have.

In most cases, this includes fields like a userId, traceId, correlationId, some form of security information. Furthermore, in most cases this does not include first-class citizen data like productTypes, as far as I know.

To come back to your original question:

If an aggregate is "metadata driven", and such metadata needs to be managed centrally together with metadata of other aggregates, is this anti pattern?

I can't say for sure that it's an anti-pattern to model a service to manage all metadata. However, it does feel like unnecessary complexity to me. Be sure to update your question with more information to clarify your idea, Bing. I'll be sure to update my response once you've done that.

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