DDD如何设计服务/汇总涉及相关实体的根

时间:2018-06-22 09:42:19

标签: design-patterns domain-driven-design repository-pattern software-design aggregateroot

我正在建立一个邀请系统,管理员只能在其中邀请

  • 尚未被邀请的用户
  • 尚未在系统中的用户(=已经是成员)

此流程涉及两个实体InvitationUser

  • 删除用户不应删除他发送的邀请
  • 更新用户的名字不应更新其所有邀请

这似乎表明InvitationsUser应该添加到两个单独的聚合中。

然后,实现上述逻辑的唯一方法是使用域服务,例如IInvitationService我可以吗?

此界面可能有两种方法:

public interface IInvitationService
{
    Task<Result> Create(Invitation invitation, CancellationToken token);
    Task<Result> Delete(Invitation invitation, CancellationToken token);
}

最后,如果我采用服务方式,将有两种可能的方式来创建邀请。

IInvitationRepository.Create() 
IInvitationService.Create()

您不觉得这令人困惑吗?

1 个答案:

答案 0 :(得分:0)

  

然后,实现上述逻辑的唯一方法是使用域服务,例如IInvitationService。我说的对吗?

这里似乎有些错误。简而言之,并不意味着我们放弃了面向对象设计的原理。

逻辑通常在变化的聚合根中实现。引入聚合模式的部分目的是使查找负责更改的代码更加容易-而不是将相同的代码分散在整个模型中,您只需考虑状态更改发生的位置并知道在哪里寻找代码。

聚合根本身仅知道其自身状态-执行更改所需的任何其他信息都作为参数传递给它。

因此,我通常不会期望您到目前为止所描述的模型部分都需要“域服务”。

域服务可能会发挥作用的情况是,对一个聚合的更改取决于另一个聚合的最新状态。例如,如果对“邀请”的特定更改取决于“用户”的当前状态,则您可以将邀请计算方法传递给负责计算更改的邀请方法,该域服务可以访问用户状态的缓存副本。 / p>

关于创建...,创建模式是很奇怪Udi Dahan's post是一个很好的起点。