在我的草稿项目中，我想知道 DDD 聚合根及其实体。 假设我的聚合是 Ticket 模型，它包含其回复的实体。我应该如何管理我的回复？每个示例都表明我应该像这样直接从 Aggregate 管理回复：
$ticket->updateReply(...);
但我真正想做的是：
$ticket->getReply(id)->update(...)
或更多：
$ticket->getReplies()->get(id)->update(...)
我的聚合 API 不仅可读，但逻辑在聚合之外看起来很少。我的想法错了吗？还是它真的很糟糕？
【问题讨论】：
标签： entity domain-driven-design aggregate aggregateroot
$ticket->updateReply(id, ...);
如何检索和更新实际回复隐藏在票证抽象后面；这意味着，除其他外，如果您想更改实现回复结构的方式，您只需要在一处更改代码（在 Ticket 的实现中）。其他一切都只与 API 对话。
$ticket->getReplies()->get(id)->update(...)
这是一个经典的反模式；消费者需要更多地而不是更少地了解 Ticket，因此更改 Ticket 的实现更难而不是更容易。
此外，由于您允许消费者直接更新回复，因此您阻止 Ticket 保护回复结构；任何验证/一致性检查现在都需要由每个消费者实施，而不是一次实施。
作为设计考虑：您希望通过 Ticket 访问以获取回复的事实可能试图告诉您，Reply 应该是与 Ticket 分开的聚合。 Reply 实体和 Ticket 实体具有连接它们的关系这一事实并不意味着它们必须是同一聚合的一部分。
【讨论】：