Domain driven design DDD-联系邀请

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

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

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

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

A） 将服务（通过抽象）注入联系人功能？这是否将域与基础架构紧密地联系在一起

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似乎没有反映“邀请期和被邀请者联系”的语言

A） 将服务（通过抽象）注入联系人功能？这是否将域与基础架构紧密地联系在一起

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

这需要理解，您传入的抽象是域服务

如果

emailService

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

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

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

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

不，因为域服务充当模型和基础结构之间的接缝——您可以轻松地将与电子邮件基础结构对话的域服务实例替换为与测试服务器对话的实例

从我的直觉来看，A似乎更好。B似乎没有反映“邀请期和被邀请者联系”的语言

B违反。这并不一定是错的（工程是一种权衡），但在其他条件相同的情况下，这并不是我的第一选择

该服务将负责将邀请转换为电子邮件，并将该消息发送到Infrastructure电子邮件服务。它还会将邀请标记为已发送。是这样吗

也许-聚合仍负责跟踪其自身状态；域服务只是处理电子邮件部分；这个域服务实际上不应该知道关于模型内部的任何信息

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

---

伪代码为您提供了基本概念——您需要考虑故障模式等等。

Ok。让我看看我是否明白这一点。我可以创建一个名为InvitationSender的域服务，它将接受域对象邀请。该服务将负责将邀请转换为电子邮件，并将该消息发送到Infrastructure电子邮件服务。它还会将邀请标记为已发送。是这样吗？