domain-driven-design - 我可以说轴突命令和事件被视为贫血模型吗？

Question

正如主题中提到的，我在这里的问题很直接。但是，请允许我在这里简要解释一下我的天真想法。我已经使用Axon大约 10 个月了。我曾经基于Hexagonal 架构设计我的项目结构，其中有两个顶级包分别用于domain和infrastructure. 此外，domain包将包含不同的域对象（如 DDD 概念中所述），例如：

1. Aggregate（这将是一个Axon aggregate类）。
2. Repository（在我的例子中，这将是一个Spring Data Repository接口）。
3. Entity（在我的情况下，这包含我用于此处所写的基于集合的一致性验证的任何查找实体）。
4. Service Port（收集Input和Ouput端口接口）。
5. Commands（代表轴突 Command对象）。

至于Events，我曾经将它们放在我编译为jar文件的不同模块上，这样我就可以将它分享给其他将在他们的项目中使用相同事件的开发人员。

我最近注意到我所有的命令和事件基本上都是贫血模型（我们应该避免的反模式）。这有什么好的做法吗？或者，它是设计故意使用的吗？

我一直在考虑将我的Command课程放在我的课程中Aggregate（作为内部课程）。至少通过使用这种方法，我最终不会有这么多贫血模型分散在外面。有什么想法吗 ？

标签： domain-driven-designaxon

Answer 1

命令被设计成反映外部世界的行为和输入结构。它们不一定反映聚合的结构。

有时，它们甚至没有明确地连接到一个单一的聚合体。将它们包含在聚合中可能会产生代码异味，因为您会考虑资源和 UI 组织，而不是事务边界和实体组。

你也违反了开闭原则。用户界面和请求结构等易失层的更改将使您编辑 Aggregate 类，这不是好的设计。

在更一般的说明...

有时，贫血与非贫血（或干与非干）的争论可能会将您推向过早且不正确的优化方向。尝试避免这个陷阱，因为您最终会在代码级别进行优化，但您的域会受到影响。

DDD 和 CQRS 指南符合可帮助您长期控制复杂性的原则。保持不同和独立的事物可以帮助您实现这一目标。