如何以 DDD 方式部分更新聚合

Question

我正在以 DDD 方式使用 C# .NET 开发应用程序。我也查了eshopcontainers，但它并没有解释我想知道什么，所以让我在这里提出一个问题。我的问题是

• 是否可以直接从批处理操作部分更新根聚合？

详情
我正在开发一个 RSVP 应用程序。现在我想做的是向尚未投票的人发送提醒邮件。我的领域模型和基础设施层是这样的。

//Domain Model
class RSVP //RootAggreagate
{
    public long Id {get; private set;}
    public List<TimeSlot> TimeSlots {get; private set;}  

    public AutoRemindRule AutoRemindRule {get; private set;}
}

class AutoRemindRule 
{
    public long Id {get; private set;}
    public int IntervalHour { get; private set; }
    public DateTimeOffset NextTriggerDate { get; private set; }
    public DateTimeOffset RemindBeginDate { get; private set; }

    //Foreign Key for Plan
    public long RSVPId


    void SetNextTriggerDate() 
    {
        //Compute NewNextTriggerDate based on IntervalHour and RemindBeginDate field.
        NextTriggerDate = NewNextTriggerDate;
    }
}

//Infrastructure Layer (EF Core)
public class MyDbContext : DbContext
{
    //Plan Aggregate
    public DbSet<RSVP> RSVPs { get; set; }
    public DbSet<TimeSlot> TimeSlots { get; set; }
    public DbSet<AutoRemindRule> AutoRemindRules { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        ...
    }
}

在这个模型中，我想运行一个批处理来定期检查AutoRemindRules 中的NextTriggerDate，如果NextTriggerDate 比现在更旧，该批处理将邮件发送给没有投票RSVP 的用户。最终，批处理通过调用SetNextTriggerDate 更新NextTriggerDate。如果我在批处理的 Usecase(Application) 层编写如下代码，我可以实现我想要的。但是，我不认为这些代码遵循 DDD 规则，因为它会部分更新聚合根。在应用层写这样的代码可以吗，或者如果没有，谁能告诉我更好的编码方式？

//Usecase(Application) layer in a batch
using (var context = new MyDbContext) 
{
    var rules = context.AutoRemindRules.Where(i => i.NextTiggerdate < DateTimeOffset.Now);
    foreach (var rule in rule)
    {
        SendRemindMail();
        rule.SetNextTriggerDate();

        context.SaveChanges();
    }
}

更新
另一种方法是创建一个方法来更新聚合根中的AutoRemindRule，并且批处理使用该方法。但是，我关心的是性能和数据库的负载。在这种情况下，除了AutoRemindRule 记录之外，该批次还必须读取一堆不必要的 RSVP 记录。我想知道是否有另一种方法可以在保持 DDD 方式的同时减少 DB 的负载。

Answer 1

可以直接从批处理操作中部分更新根聚合吗？

简短的回答是：不。

聚合的重点是封装数据并公开业务操作，以便检查和执行验证和不变量。如果您让外部进程修改聚合的数据，那么它完全违背了它们的目的。

可能的解决方案：

1. 不要使用聚合。如果您拥有的只是一个包含日期和一些数据的表和一个批处理作业，但没有或几乎没有要强制执行的业务逻辑，那么只需执行此操作：一个表和一个批处理作业。乍一看，您似乎唯一需要强制执行的是 NextTriggerDate 是在将来的某个时间，您可以将其编码到批处理作业中。但是我可以想象你可以有更多的规则，比如不要触发超过X次，不要早于1天触发等等。或者甚至让聚合决定下一个触发日期，基于一些内部逻辑（首先1 天后触发，2 天后触发第二次，依此类推）。聚合对于这些事情非常方便，因为每个聚合都将存储计算下一次状态更改所需的状态。

2. 评估加载完整 RSVP 聚合是否确实存在问题。对于大多数应用程序来说，加载一些额外的列不应该对性能造成很大的影响，并且为了获得聚合封装其业务逻辑的好处，以防你需要做我在前面提到的那些事情时所需要付出的必要代价观点。相反，如果您正在构建具有大规模和少量业务逻辑的功能，那么请考虑另一种方法。

1234563聚合而不加载该集合。您应该对需要该集合的聚合根操作进行编码，以验证该集合是否已加载，否则会失败，以避免出现错误。