DDD:更新实体多个属性的指南

本文关键字：属性 更新 实体 DDD | 更新日期: 2023-09-27 18:21:46

因此，我决定学习DDD，因为它似乎可以解决我一直面临的一些架构问题。虽然有很多视频和示例博客，但我还没有遇到一个能指导我解决以下场景的：

假设我有实体

public class EventOrganizer : IEntity
{
    public Guid Id { get; }
    public string Name { get; }
    public PhoneNumber PrimaryPhone { get; }
    public PhoneNumber AlternatePhone { get; private set; }
    public Email Email { get; private set; }
    public EventOrganizer(string name, PhoneNumber primaryPhoneNr)
    {
        #region validations
        if (primaryPhoneNr == null) throw new ArgumentNullException(nameof(primaryPhoneNr));
        //validates minimum length, nullity and special characters
        Validator.AsPersonName(name);
        #endregion
        Id = new Guid();
        Name = name;
        PrimaryPhone = primaryPhoneNr;
    }
}

我的问题是：假设这将被转换并提供给MVC视图，并且用户想要更新AlternatePhone、电子邮件和许多其他有意义的属性，这些属性存在于给定的有界上下文中（为简洁起见，未显示）

我知道正确的指导是为每个操作都有一个方法，但（我知道这是一种反模式）我忍不住想知道这是否最终会触发数据库上的多个更新调用。

这是如何处理的？在接下来的某个地方，会有什么东西将我的EventOrganizer映射到某个东西吗？比如DbEventOrganiz器，并收集对域实体所做的所有更改，并一次性应用这些更改？

DDD:更新实体多个属性的指南

DDD更适合基于任务的UI。您所描述的内容非常面向CRUD。在您的情况下，单个属性被视为独立的数据字段，其中一个或多个属性可以通过单个通用业务操作（更新）进行更新。

如果你想成功使用DDD，你必须对你的域进行更深入的分析。

为什么有人会一起更新所有这些字段？用户试图通过这样做来实现什么样的隐含业务操作？是否有更具体的业务流程可以通过将PrimaryPhone、AlternatePhone和Email一起更改来表达？

也许这是在改变EventOrganizer的ContactInformation？如果是这种情况，那么您可以对EventOrganizer上的单个ChangeContactInformation操作进行建模。然后，UI将发送ChangeContactInformation命令，而不是update命令。

至于聚合根（AR）的持久性，如果您使用RDBMS，这通常由类似于ORM的NHibernate来处理。然而，还有其他方法可以持久化AR，如Event Sourcing、NoSQL DB，甚至可以在RDBMS中存储JSON或任何其他数据交互更改格式。

你的问题很宽泛！

EventOrganizer本身不应该更新任何内容。您应该将更新代码与实体完全分离。另一个类将使用EventOrganizer对象并更新DB。这被称为"持久性无知"，使代码更加模块化和内聚。

创建视图模型是很常见的，该类的目的是以所需的确切形式为视图提供所需的精确数据。您需要从EventOrganizer创建视图模型，之后视图可以通过编程或绑定对其进行更新。当您准备好保存更改时，您需要从视图模型更新EventOrganizer，并将其传递到更新程序上。当项目很小很简单时，这似乎是一个你不需要的层，但随着复杂性的增加，它变得非常宝贵。

相关文章：