Question

在我的草案项目期间，我想知道DDD聚合根及其实体。让我们说我的聚合是Ticket模型，它包含其回复的实体。我该怎样管理我的回复？每个示例都表明我应该直接从Aggregate管理回复：

$ticket->updateReply(...);

但我真正想做的是：

$ticket->getReply(id)->update(...)

或更多：

$ticket->getReplies()->get(id)->update(...)

我的聚合Api不仅仅是可读的，而且在Aggregate之外的逻辑看起来很少。我的想法错了吗？或者它真的很糟糕？

Answer 1

$ticket->updateReply(id, ...);

如何检索和更新实际回复隐藏在故障单抽象之后;这意味着，除其他外，如果您想要改变实现回复结构的方式，您只需要在一个地方（在Ticket的实现中）更改代码。其他所有内容都只是与API进行对话。

$ticket->getReplies()->get(id)->update(...)

这是一种经典的反模式;消费者需要更多地了解Ticket，而不是更少，因此更改Ticket的实现更难而不是更容易。

此外，由于您允许使用者直接更新回复，因此您可以阻止Ticket保护回复结构;任何验证/一致性检查现在都需要由每个消费者实施，而不是一次性实施。

作为一个设计考虑因素：您希望通过Ticket到达回复的事实可能试图告诉您，Reply应该是Ticket的单独聚合。 Reply实体和Ticket实体具有连接它们的关系这一事实并不意味着它们必须属于同一个Aggregate。