Domain driven design 用户聊天信息应该是聚合的吗？

在对典型的聊天应用程序（具有无限聊天）建模时，是否应将每条消息视为聚合实例

聚合应该保持小，并且不能想到其他合适的小候选来包含用户消息。但同时，我只是想知道，我应该为系统中这样一个小对象使用聚合概念

是否应将每条消息视为聚合实例

这是一个好问题，但问错了人，因为我们不了解您的业务：）

聚合是事务对象边界的同义词 一致性。[…]正确设计的骨料是可以 以业务需要的方式进行修改，同时提供 业务规则作为单个事务的一部分保持一致。[...] 聚合主要涉及一致性边界及其设计 不应受创建对象图的需要的控制。[…]~实施领域驱动设计，沃恩·弗农

聚合主要是关于业务规则中的事务一致性。您应该询问业务部门是否有关于单个聊天信息的任何规则。在一个典型的聊天应用程序中，可能不会，但你必须询问业务

---

在我可以想象的最简单的聊天应用程序中，我的聊天信息宁愿是一个值对象。或者我甚至不会像曾提到的那样使用DDD。我想不出我需要什么业务规则，它肯定是不可变的。

DDD是一种应用于涉及业务规则的复杂解决方案的模式。聊天应用程序听起来不像是一个复杂的应用程序，在这个应用程序中，您可以通过应用DDD获得很多附加值。并不是每种类型的应用程序都适合DDD，即简单的CRUD服务，基本上转储数据库并直接写入数据库，几乎没有逻辑（输入验证除外）。不过，我很确定应该有消息传递应用程序使用DDD原则来建模体系结构。我不会打赌。聊天应用程序代表什么样的业务流程？DDD是关于将业务流程转换成软件的。如果你是某种聊天服务提供商，那么在创建、计费和管理聊天服务（即将其作为服务出售给公司）时可能会涉及到一些业务逻辑，但是对于发送消息本身，不要认为这是一个聚合。发送/获取消息可能是域服务（用于验证权限或执行计费），但不是聚合，因为消息本身没有业务逻辑。好的，我明白你的意思。但是，如果存在一些功能，如编辑消息，以及一些角色，如无法编辑旧消息等？当域中的重要过程或转换不是实体或值对象的自然职责时，请将操作作为声明为服务的独立接口添加到模型中。根据模型的语言定义接口，并确保操作名称是通用语言的一部分。使服务无状态。-来自Eric Evans的“领域驱动设计”。TL；DR：您在负责编辑的域服务中进行此类检查。谢谢您的重播。那么编辑消息呢？编辑/更新是简单CRUD的一部分。但是如果有一些规则，比如什么时候可以编辑，为什么可以编辑，那么可以继续使用聚合。如我所说，如果这是您系统中唯一的业务规则，我宁愿不使用DDD，但如果您正在学习或知道它很快就会改变，请继续。