待更新模块-域实体还是值对象？

Question

我正在将大型经典的ASP Web应用程序转换为具有域驱动设计的ASP.Net MVC。 尽管我的大部分领域都适合DDD，但我一直遇到不适合使用纯DDD方法的情况。 例如，我的应用程序的读取端与写入端明显不同。 没问题，我创建了一个单独的读取模型，并实现了CQRS的简化版本（没有事件源，没有单独的数据库）。 另一个问题是批量数据库操作。 没问题，这是作为服务实现的。 这是我目前的困惑。 我们的系统允许用户对系统进行更改，这些更改在将来的某个日期生效。 为了适应这一点，我们有一个数据库表，用于存储直到生效日期的未决更改。 在生效日期，将运行自动化任务并执行实际的数据库更新。 更新任务可以包括域逻辑，因此该部分适合DDD，这不是问题。 为了帮助可视化正在发生的事情，下面是处理未决更新的类：

public class PendingChanges
{
    public int EntityID {get; set;}
    public string FromTable {get; set;}
    public string DetailField {get; set;}
    public string NewValue {get; set;}
    public DateTime EffectiveDate {get; set;}
    public DateTime EnteredDate {get; set;}
    public int UserID {get; set;}
    public string UserName {get; set;}
    public string UserArea { get; set; } 

   // Business logic and validation here? 
} 

如您所见，这是一个通用类，可以处理对各种数据库表的更新。 它基本上存储要更新的数据库列，该列将是的新值，它所属的表，生效日期和一些日志记录数据。

所以这是我的问题：应该将收集挂起更新并将其存储在挂起更新表中的逻辑建模为域对象，还是应该以其他方式（例如作为服务）进行处理？

换句话说，PendingChanges本身是具有自己域逻辑的域实体吗？ 有一些适用于PendingChanges的业务规则，不同于发生更改的实体。 例如，构成UserArea的内容可以视为业务规则，就像FromTable的合法值一样，更不用说验证了。

还是PendingChanges是一个值对象，因为它可以在不同的域对象之间重用？ 如果是这样，使用PendingUpdatesService是否更有意义？

Answer 1

域的一部分是进行数据库更新的概念，即您是否正在构建数据库管理/报告软件？ 如果PendingChanges对您的Domain有意义，那么也许是一个实体，尽管这种技术上的重要性较小，但是获取正确的域建模更为重要。 如果PendingChanges是您的应用程序用来更新数据库中（域）内容的类，则它与DDD或您的域无关。 它是基础架构的一部分。 虽然仍然需要良好的OOP，但是这里没有DDD流行语。

顺便说一句，如果一个对象有一个ID，它通常是一个实体。