代码之家 › 专栏 › 技术社区 › Seb

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

aggregateroot software-design repository-pattern domain-driven-design design-patterns

1

Seb · 技术社区 · 7 年前

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

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

Invitation User .

更新用户的名字不应该更新他所有的邀请

Invitations 用户

IInvitationService

这个接口有两种方法:

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

IInvitationRepository.Create() 
IInvitationService.Create()

1 回复 | 直到 7 年前

1

0

VoiceOfUnreason 7 年前

然后,实现上述逻辑的唯一方法是使用像iInvitationService这样的域服务。我说得对吗?

这里好像出了点问题。简而言之, domain-driven-design 并不意味着我们放弃了面向对象设计的原则。

逻辑通常在正在更改的聚合根中实现。引入聚合模式的部分目的是为了更容易找到负责进行更改的代码——而不是让相同的代码分散在模型上,您可以考虑状态更改发生的位置并知道在哪里查找代码。

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

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

域服务可能发挥作用的情况是,对一个聚合的更改取决于不同聚合的最近状态。例如,如果对“invitation”的特定更改取决于“user”的当前状态,则可以将访问用户状态缓存副本的域服务传递给负责计算更改的invitation方法。

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