DDD -联系邀请

Question

我正在工作的领域是一个会员制度。我有一个领域概念，称为注册邀请期，在此期间，用户可以邀请其他人注册成为会员。报名邀请期可以是开放/关闭，并持有邀请。邀请函是一个名字和电子邮件地址。

我有一个要求:当一个报名邀请期是开放的，它应该联系任何未联系的邀请。在我看来，这是招生邀请期班应该负责的事情。它可以访问满足这一业务需求所需的所有信息。

接下来，我有一个电子邮件服务。它负责获取模板，构建和发送电子邮件。这是基础设施。

所以我的问题。注册邀请期域对象应如何与电子邮件服务交互。

将服务(通过抽象)注入到联系函数中？这是否将域与基础结构紧密地联系在一起？

var period = repo.Get(id);
period.ContactInvitations(emailService);

( B)编写查询邀请期信息的域服务？

(In Service)
var period = repo.Get(id);
if (period.IsOpen)
{
   var unconcacted = period.GetUncontactedInvitations();
   foreach(var i in uncontacted)
   {
        var email = BuildEmailFromInvitaion(i);
        emailService.Send(email);
   }
}

从我的直觉来看，A看起来好多了。B似乎没有反映“邀请期接触受邀者”的语言。

Answer 1

将服务(通过抽象)注入到联系函数中？这是否将域与基础结构紧密地联系在一起？

这是因为您所传递的抽象是域服务。

var period = repo.Get(id);
period.ContactInvitations(emailService);

这里的拼写非常好，前提是emailService是域服务；它公开的电子邮件功能应该用域模型的语言表示。

在这种模式中，域服务充当一个适配器，它接受域概念作为参数，并将它们传递给电子邮件基础结构。

这是否将域与基础结构紧密地联系在一起？

不，因为域服务充当模型和基础结构之间的接缝--您可以很容易地将与电子邮件基础结构对话的域服务实例替换为一个与测试双机对话的实例。

从我的直觉来看，A看起来好多了。B似乎没有反映“邀请期接触受邀者”的语言。

B违反告诉我，别问。这并不一定是错误的(工程就是权衡)，但在其他条件相同的情况下，这并不是我的第一选择。

该服务将负责将邀请转换为电子邮件，并将该消息发送到基础设施电子邮件服务。这也将标志着发出的邀请。是那么回事吗？

也许--聚合仍然负责跟踪自己的状态；域服务只是处理电子邮件部分；这个域服务实际上不应该知道模型的内部结构。

Period::ContactInvitations(emailService) {
    for(invitation : uncontacted) {
        if (emailService.contact(...)) {
            this.onContacted(invitation);
        }
    }
}

伪代码给你一个基本的想法--你会想要思考失败的模式等等。