【问题标题】:Updating DDD Aggregates with Collections使用集合更新 DDD 聚合
【发布时间】:2018-07-20 21:18:36
【问题描述】:

所以,我有一个聚合 (Project),其中包含一组实体 (ProjectVariables)。变量上没有 ID,因为它们在项目聚合根之外没有身份。

public class Project
{
    public Guid Id { get; set; }
    public string Name { get; set; }

    public List<ProjectVariable> ProjectVariables { get; set; }

}


public class ProjectVariable
{
    public string Key { get; set; }
    public string Value { get; set; }
    public List<string> Scopes { get; set; }
}

该项目的用户界面是一个 Angular Web 应用程序。用户访问项目的详细信息,并可以添加/删除/编辑项目变量。他可以改名。直到用户单击保存并且 Web 应用程序将一些 json 发布到后端,后端才会将其传递到域,否则不会对数据库进行任何更改。

根据 DDD,正确的做法是在 Aggregate 根上使用小而简洁的方法对它们进行原子更改。此域中的示例可以是方法 Project.AddProjectVariable(projectVariable)。

为了保持这种做法,这意味着前端应用程序需要跟踪更改并提交如下内容:

public class SaveProjectCommand
{
    public string NewName { get; set; }

    public List<ProjectVariable> AddedProjectVariables { get; set; }

    public List<ProjectVariable> RemovedProjectVariables { get; set; }

    public List<ProjectVariable> EditedProjectVariables { get; set; }
}

我想也可以发布现在编辑的项目,从 repo 中检索原始项目,然后对它们进行比较,但这似乎有点荒谬。

此对象将被转换为服务层方法,该方法将调用聚合根上的方法来完成预期的行为。

所以,这就是我的问题所在......

  1. ProjectVariables 没有 ID。它们是瞬态对象。如果我需要从 UI 跟踪更改中删除它们,如何识别需要在聚合上删除的那些?同样,他们没有身份证明。我可以将代理 ID 添加到 ProjectVariables 实体中,但这似乎是错误和肮脏的。
  2. 我的 UI 中的更改跟踪是否让 UI 做得太多?
  3. 是否有替代机制?一种想法是每次保存项目聚合根时只需替换项目聚合根中的所有项目变量。那不是让我添加一个 Project.ClearVariables() 和使用 Project.AddProjectVariable() 来替换它们吗? Project.ReplaceProjectVariables(List) 似乎很“CRUDish”
  4. 我是否遗漏了一些关键组件?在我看来,DDD 原子方法不能很好地与您可以在提交之前对实体进行许多不同更改的模式相结合。

【问题讨论】:

    标签: c# angular rest domain-driven-design


    【解决方案1】:

    根据 DDD,适当的做法是小而简洁 对 Aggregate 根进行原子更改的方法。

    我不会那样说。这些方法应尽可能反映具有域意义并与通用语言中的动词或名词相对应的内聚操作。但由此发生的状态转换不一定很小,它们可以改变大量的聚合数据。

    我同意这并不总是可行的。有时,您只想逐个字段地更改某些实体。如果这种情况发生得太多,也许是时候考虑从富领域模型方法更改为 CRUD 方法了。

    ProjectVariables 没有 ID。它们是瞬态对象。

    所以他们可能是Value Objects 而不是实体。

    您通常不会修改值对象而是替换它们(特别是如果它们是不可变的)。 Project.ReplaceProjectVariables(List) 或类似的可能是您最好的选择。我不认为它太粗俗。此处的纯 CRUD 意味着您在 Variables 属性上只有一个 setter,甚至不允许创建方法并根据需要对其命名。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2020-08-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-02-02
      相关资源
      最近更新 更多