Asp.net mvc 挂起的更新模块-域实体或值对象？

我正在将一个大型经典ASP web应用程序转换为具有域驱动设计的ASP.NETMVC。虽然我的很多领域都很适合DDD，但我一直遇到纯DDD方法不合适的情况。例如，我的应用程序的读端与写端差别很大。没问题，我创建了一个单独的读取模型，并实现了CQR的简化版本（没有事件源，没有单独的数据库）。另一个问题是批量数据库操作。没问题，这是作为服务实现的。这是我目前的困惑。我们的系统允许用户对系统进行更改，这些更改在将来某个日期生效。为了适应这种情况，我们有一个数据库表，它存储在生效日期之前的挂起的更改。在生效日期，自动任务将运行并执行实际的数据库更新。更新任务可以包括域逻辑，这样部件就可以与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本身就是一个具有自己域逻辑的域实体吗？有一些适用于挂起更改的业务规则与正在进行更改的实体不同。例如，构成用户区的内容可以被视为业务规则，也可以被视为FromTable的合法值，更不用说验证了

---

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

进行数据库更新（即您正在构建数据库管理/报告软件）的概念是否属于该领域的一部分？如果PendingChanges对您的领域有意义，那么可能是一个实体，尽管这个技术性问题不那么重要，但获得正确的领域建模更为重要。如果PendingChanges是应用程序用来更新数据库中（域）内容的类，那么它与DDD或域无关。它是基础设施的一部分。虽然仍然需要良好的OOP，但这里没有DDD术语

---

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

这听起来非常技术化，也许现在可以使用最简单的解决方案-一个过程事务脚本-然后从那里开始？首先，PendingChanges类在应用程序的不同部分的各种场景中使用，因此，从可重用性的角度来看，纯过程方法不是最佳的，尽管混合方法在这里可能最有意义。当然，PendingChanges类的数据库更新机制属于infrastructure，我知道这一点，但是类本身呢？我倾向于将其作为价值对象或DTO。这将在项目结构中占据什么位置？如何调用数据库方法？直接从基础架构层或通过服务或接口？因为PendingChanges与域无关，所以它是实体还是值对象并不重要。作为一个实用类，您可能有一个基础设施项目或类似项目。这种方法对我来说似乎很奇怪，我的意思是我会使用命令来更新模型，然后由后台进程执行，但是像这样的类我不知道。可以肯定的是，它不是域的一部分。这里似乎有一种带有延迟消息的队列形式。这是非常数据驱动的，因为您的核心领域与数据库管理无关，所以应该以纯技术的方式进行处理。当然，这些业务规则的处理可能会导致域中的不一致，这将需要某种形式的处理，最终可能会在域中结束。