DDD 实体和 EntityType 参考

发布于 2025-01-14 16:13:15 字数 784 浏览 1 评论 0原文

我正在学习 DDD,这是我遇到的问题。我有两个聚合(简化):

class NoteType : AggregateRoot {
  int noteTypeId
  string name
  string fields[]
  ... code omitted ...
}

class Note : AggregateRoot {
  int noteId
  int noteTypeId
  map<str, str> fieldValues

  setFieldValue(fieldName, fieldValue) {
    // I want to check that fieldName is present in Notes.fields
    // and later fieldValues[field.name] = fieldValue
  }
  ... code omitted ...
}

我听说聚合应该仅通过 ID 相互引用。在这种情况下,我无法访问 NoteType.fields。我找到了几种方法来做到这一点,但不确定哪一种更好:

  1. 通过构造函数将 NoteType 实例传递到 Note 模型中(不要通过 ID 引用)
  2. 在 < code>setFieldValue 加载 NoteType
  3. 使用将进行检查的服务(这可能会导致所有 Note 逻辑都在此服务中实现,因为 Note 高度依赖于 NoteType)

您有什么建议?

I'm learning DDD and here is a problem I faced. I have two Aggregates (simplified):

class NoteType : AggregateRoot {
  int noteTypeId
  string name
  string fields[]
  ... code omitted ...
}

class Note : AggregateRoot {
  int noteId
  int noteTypeId
  map<str, str> fieldValues

  setFieldValue(fieldName, fieldValue) {
    // I want to check that fieldName is present in Notes.fields
    // and later fieldValues[field.name] = fieldValue
  }
  ... code omitted ...
}

I've heard that aggregates should reference to each other by ID's only. It this case I can't access NoteType.fields. I found several ways to do so, but not sure which one is better:

  1. Pass NoteType instance into the Note model via constructor (do not reference by ID)
  2. Use repository in setFieldValue to load NoteType
  3. Use service which will do the check (this may cause all the Note logic to be implemented in this service, since Note highly dependent on NoteType)

What do you suggest?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

坏尐絯℡ 2025-01-21 16:13:15

你有什么建议?

当聚合需要的时候,将聚合需要的信息传递给聚合。

  setFieldValue(fieldName, fieldValue, noteType) {
    // Now you have the data that you need to verify the noteType.fields
  }

有时,如果您无法从聚合外部判断您需要什么信息,那么您可以传递查找该信息的功能。

  setFieldValue(fieldName, fieldValue, notes) {
    // Use the provided capability to get what you need
    noteType = notes.get(this.noteTypeId)

    // the do the useful work
    this.setFieldValue(fieldName, fieldValue, noteType)
  }

当然,如果您唯一需要的是字段,那么您可能更喜欢只使用该属性:

setFieldValue(fieldName, fieldValue, fields)

设计就是我们所做的事情,当我们想要得到比仅仅做得到更多的东西时。 -- 露丝·马兰

在领域驱动设计中,一个常见的“我们想要的”是拥有“业务逻辑”,这意味着我们实施对我们的业务很重要的信息变更策略,与描述如何读取和存储该信息的“管道”分开。

What do you suggest?

Pass the information that the aggregate needs to the aggregate when it needs it.

  setFieldValue(fieldName, fieldValue, noteType) {
    // Now you have the data that you need to verify the noteType.fields
  }

Sometimes, if you can't tell from outside the aggregate what information you need, then you instead pass the capability to look up that information

  setFieldValue(fieldName, fieldValue, notes) {
    // Use the provided capability to get what you need
    noteType = notes.get(this.noteTypeId)

    // the do the useful work
    this.setFieldValue(fieldName, fieldValue, noteType)
  }

Of course, if the only thing you need is the fields, then you might prefer to work only with that property:

setFieldValue(fieldName, fieldValue, fields)

Design is what we do, when we want to get more of what we want than we'd get by just doing it. -- Ruth Malan

In Domain Driven Design, a common "what we want" is to have the "business logic", meaning our implementation of the policies of information change that are important to our business, separated from the "plumbing" that describes how to read and store that information.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文