待定更新模块 - 域实体或值对象？

我正在将大型经典ASP网页应用程序转换为带有域驱动设计的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更有意义吗？

来源

2014-04-22 Louise Eggleton

这听起来很技术化，也许现在是最简单的解决方案 - 一个程序化的交易脚本 - 并从那里拿走它？ –

首先，PendingChanges类用于应用程序不同部分的各种场景，因此从可重用性的角度来看，纯粹的程序方法并不是最优的，尽管混合方法在这里最有意义。 –

是域的一部分做数据库更新的概念，即你建立数据库管理/报告软件？如果PendingChanges对您的域有意义，那么可能是一个实体，虽然这个技术性问题较少，但获得正确的域建模更重要。如果PendingChanges是您的应用程序用来更新数据库中的（域）事物的类，那么它与DDD或您的域无关。它是您基础设施的一部分。尽管如此，仍然需要良好的面向对象程序设计，但在这里没有DDD流行语。

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

来源

2014-04-22 23:29:55 MikeSW

当然PendingChanges类的数据库更新机制属于基础设施，我知道，但是类本身呢？我倾向于这是一个价值对象或DTO。那些生活在项目结构中？那么应该如何调用数据库方法？直接从基础架构层或通过服务或接口？ –

由于PendingChanges与域无关，因此它是否是实体或值对象并不重要。作为一个工具类，你可能有一个基础设施项目或类似的项目。这种方法对我来说似乎很陌生，我的意思是我会使用命令来更新稍后由后台进程执行的模型，但是我不知道这样的类。什么是确定它不是域的一部分。 – MikeSW

你在这里看起来有一种带有延迟消息的队列形式。这是非常数据驱动的，因为你的核心领域不是数据库管理相关的，它应该以纯粹的技术方式处理。当然，对这些业务规则的处理可能会导致域中的不一致，从而需要某种形式的处理，这些处理可能最终会在域中出现。 –

待定更新模块 - 域实体或值对象？

回答

相关问题