代码之家 › 专栏 › 技术社区 › PaweÅ Babilas

管理聚合实体(DDD)

aggregateroot aggregate domain-driven-design entity

0

PaweÅ Babilas · 技术社区 · 6 年前

在我的项目草案中,我想知道DDD聚合根及其实体。假设我的聚合是票证模型,它包含其回复的实体。我应该如何管理我的回复?每个示例都表明,我应该直接从聚合中管理回复,如下所示:

$ticket->updateReply(...);

但我真正想做的是:

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

或更多:

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

我的聚合Api可读性很强,但逻辑在聚合之外看起来很少。我的想法错了吗?还是真的很糟糕?

1 回复 | 直到 6 年前

1

0

VoiceOfUnreason 6 年前

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

如何检索和更新实际回复隐藏在票证抽象背后;这意味着,除其他外,如果您试图更改实现回复结构的方式,您只需要在一个地方(在Ticket的实现中)更改代码。其他一切都与API有关。

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

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

此外,由于您允许消费者直接更新回复,因此您排除了Ticket对回复结构的保护;现在,任何验证/一致性检查都需要由每个消费者实施,而不是一次性实施。

作为设计考虑:您希望通过Ticket获得回复的事实可能是试图告诉您回复应该是Ticket的单独聚合。Reply实体和Ticket实体具有连接它们的关系这一事实并不意味着它们必须是同一聚合的一部分。