1

我正在将一个大型经典 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 是否更有意义？

4

1 回答 1

2

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

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

于 2014-04-22T23:29:55.147 回答