我可以说 Axon 命令和事件被视为贫血模型吗？
Can I say Axon Commands and Events are considered as anemic models?
正如主题中提到的，我这里的问题很直截了当。
但是，请允许我在这里对我的 天真 想法做一些简单的解释。
我已经使用 Axon 大约 10 个月了。我曾经基于 Hexagonal 架构 设计我的项目结构，其中两个顶级包分别用于 domain 和 infrastructure。
此外，domain 包将包含不同的域对象（如 DDD 概念中所述），例如：
Aggregate（这将是一个 Axon aggregate class）。Repository（在我的例子中，这将是一个 Spring Data Repository 接口）。Entity（在我的例子中，这包含我用于基于集合的一致性验证的任何查找实体，如所写 here）。Service Port（Input 和 Ouput 端口接口的集合）。Commands（代表AxonCommand对象）。
至于Events，我曾经把它们放在一个不同的模块中，然后编译成一个jar文件，这样我就可以把它分享给其他要使用相同事件的开发者他们的项目。
我最近注意到我所有的命令和事件基本上都是贫血模型（我们应该避免的反模式）。
这方面有什么好的做法吗？或者，它是设计有意使用的东西吗？
我一直在考虑将我的 Command classes 放在我的 Aggregate class 中（作为内部 classes）。至少通过使用这种方法，我最终不会有那么多贫血模型散落在外面。有什么想法吗？
命令被设计为反映外部世界的行为和输入结构。它们不一定反映聚合的结构。
它们有时甚至没有清楚地连接到一个集合体。将它们包含在聚合中可能会产生代码味道，因为您当时是在考虑资源和 UI 组织，而不是事务边界和实体组。
你也违反了开闭原则。用户界面和请求结构等易失性层的更改将使您编辑聚合 class，这不是好的设计。
更笼统的说明...
有时，关于贫血与非贫血（或干燥与非干燥）的争论可能会将您推向过早且不正确的优化方向。尽量避免这个陷阱，因为您最终会在代码级别进行优化，但您的域会受到影响。
DDD 和 CQRS 指南符合可帮助您长期控制复杂性的原则。保持清晰和独立的事物可以帮助您实现这一目标。
首先，在 DDD 中，你的域必须没有任何框架，只使用纯语言库。
那么，混合命令和聚合不是一个好的解决方案。我认为 Commands 属于 Port 而 Aggregates 属于 Hexagone。
最后，DDD 强调了域的发现，感谢专家。是你做的吗 ？否则，如果您只使用 Tactics 模式，您将错过 DDD 最重要的部分之一。
正如主题中提到的，我这里的问题很直截了当。
但是，请允许我在这里对我的 天真 想法做一些简单的解释。
我已经使用 Axon 大约 10 个月了。我曾经基于 Hexagonal 架构 设计我的项目结构，其中两个顶级包分别用于 domain 和 infrastructure。
此外，domain 包将包含不同的域对象（如 DDD 概念中所述），例如：
Aggregate（这将是一个 Axonaggregateclass）。Repository（在我的例子中，这将是一个 Spring Data Repository 接口）。Entity（在我的例子中，这包含我用于基于集合的一致性验证的任何查找实体，如所写 here）。Service Port（Input和Ouput端口接口的集合）。Commands（代表AxonCommand对象）。
至于Events，我曾经把它们放在一个不同的模块中，然后编译成一个jar文件，这样我就可以把它分享给其他要使用相同事件的开发者他们的项目。
我最近注意到我所有的命令和事件基本上都是贫血模型（我们应该避免的反模式）。 这方面有什么好的做法吗？或者，它是设计有意使用的东西吗？
我一直在考虑将我的 Command classes 放在我的 Aggregate class 中（作为内部 classes）。至少通过使用这种方法，我最终不会有那么多贫血模型散落在外面。有什么想法吗？
命令被设计为反映外部世界的行为和输入结构。它们不一定反映聚合的结构。
它们有时甚至没有清楚地连接到一个集合体。将它们包含在聚合中可能会产生代码味道，因为您当时是在考虑资源和 UI 组织，而不是事务边界和实体组。
你也违反了开闭原则。用户界面和请求结构等易失性层的更改将使您编辑聚合 class，这不是好的设计。
更笼统的说明...
有时，关于贫血与非贫血（或干燥与非干燥）的争论可能会将您推向过早且不正确的优化方向。尽量避免这个陷阱，因为您最终会在代码级别进行优化，但您的域会受到影响。
DDD 和 CQRS 指南符合可帮助您长期控制复杂性的原则。保持清晰和独立的事物可以帮助您实现这一目标。
首先，在 DDD 中，你的域必须没有任何框架，只使用纯语言库。
那么，混合命令和聚合不是一个好的解决方案。我认为 Commands 属于 Port 而 Aggregates 属于 Hexagone。
最后，DDD 强调了域的发现，感谢专家。是你做的吗 ？否则，如果您只使用 Tactics 模式，您将错过 DDD 最重要的部分之一。