会议和邀请/如何在 DDD 上下文中建模邀请机制？

Question

在领域驱动设计的背景下：

我的域是关于会议和邀请发送的。
一个例子：

用户可以创建一个名为“MyMeeting”的会议，并且他可以通过一些专门的“邀请”来邀请他选择的用户。

我阅读了 Vaughn Vernon 的书 (IDDD)，并得出结论，Meeting 和 Invitation 之间不存在不变量。

所以，我开始创建两个不同的聚合根：

• Meeting（身份证、姓名等）
• Invitation（meetingId，发生在，接收者（目标用户））

我意识到可能会同时发送多个邀请。
所以我想在InvitationRepository 中创建一个特殊查询，旨在一次保存所有邀请：

void addAll(List<Invitation> invitations)

问题在于它引入了与 Invitation 聚合结构的不一致。
说明：
该结构涉及每个Invitation 拥有自己的关联meetingId。
而addAll 旨在添加多个关于同一MeetingId 的邀请；换句话说：每个邀请都通用。

因此，如果我想避免多个数据库查询，由于当前的结构，这种实现会很丑：

void addAll(List<Invitation> invitations) {

    //meetingId supposed to be the same across those invitations, 
    //an ugly way to retrieve it would be : 
    MeetingId meetingId = invitations.get(0).getMeetingId(); 
    Date occurredOn = invitations.get(0).getOccurredOn();
    List<User> receivers = new ArrayList();

    for(invitation: Invitations) {
      receivers.add(invitation.getReceiver());
    }

    //then perform the query saving all invitations at once
    //=> one invitation for each receiver
}    

处理一次保存多个Invitations的情况有什么好的方法？
是否应该更改域结构？

---

我想到了InvitationRepository中的那些签名：

void add(List<Invitation> invitations)            
void addAll(List<Invitation> invitations, MeetingId meetingId, DateTime: occurredOn)    

或者甚至使用名为 Invitations 的包装器：

class Invitations {  //note the plurality
   MeetingId meetingId; 
   DateTime occurredOn;
   List<Invitation> invitations;
   //........ 
} 

=> void addAll(Invitations invitations)
将嵌套邀请（聚合根）保存在同一个数据库查询中。

这样，在addAll 实现的情况下，我不会从invitations itself 中选择meetingId 和occurredOn，这会导致一种DRY 违规但保持整体不那么丑陋。

你怎么看？

Answer 1

为什么不简单地这样做呢？

public class InvitationBulkRequest {
     private final List<Invitation> invitations = new ArrayList<>();
     private final MeetingId meetingId;
     private final DateTime occurredOn

     public InvitationBulkRequest(MeetingId meetingId, DateTime occurredOn) {
         this.meetingId = Objects.requireNonNull(meetingId);
         this.occurredOn = Objects.requireNonNull(occurredOn);
     }

     public void invite(User recipient) {
         invitations.add(new Invitation(meetingId, occurredOn, recipient);
     }

     public void send() {
         invitations.forEach(Invitation::send);
     }
}

这样，您可以很好地封装所有邀请之间的公共数据，并确保它们都是一致的。

Answer 2

你确定你的设计是合理的吗？您可能正试图将稍微倾斜的设计硬塞进 DDD 语言中。

我认为会议有一些不变量。也许我们至少需要 2 名参与者。与一个人会面是相当乏味的。现在我假设邀请有一些与此相关。难道邀请是用来通知参与者和跟踪接受的机制吗？

整理其中一些内容可能会为您提供有关如何解决问题的线索。也许你可以拥有Meeting 1-* Participant，它由Invitation 表示，就像Order 1-* Product 由OrderItem 表示一样。

Answer 3

addAll 方法的正确实现是不关心业务规则的。如果邀请是独立的聚合，那么存储库应该这样对待它们。在循环中调用add 或调用addAll 之间不应存在不同的语义。

Set<Invitation> invitations = meeting.inviteAll(invitees);           

repository.addAll(invitations);

这里的inviteAll 方法封装了确保所有邀请都链接到同一个会议所必需的业务逻辑。

如果在所有邀请共享相同的meetingId 时可以进行一些持久性优化，那么没有什么可以阻止您检查存储库中的所有邀请并查看是否有可能的优化。

例如，您可以循环所有邀请，并使用Map 将它们按meetingId 分组。