DDD 实体和 EntityType 参考
我正在学习 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
。我找到了几种方法来做到这一点,但不确定哪一种更好:
- 通过构造函数将
NoteType
实例传递到Note
模型中(不要通过 ID 引用) - 在 < code>setFieldValue 加载
NoteType
- 使用将进行检查的服务(这可能会导致所有 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:
- Pass
NoteType
instance into theNote
model via constructor (do not reference by ID) - Use repository in
setFieldValue
to loadNoteType
- 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当聚合需要的时候,将聚合需要的信息传递给聚合。
有时,如果您无法从聚合外部判断您需要什么信息,那么您可以传递查找该信息的功能。
当然,如果您唯一需要的是字段,那么您可能更喜欢只使用该属性:
在领域驱动设计中,一个常见的“我们想要的”是拥有“业务逻辑”,这意味着我们实施对我们的业务很重要的信息变更策略,与描述如何读取和存储该信息的“管道”分开。
Pass the information that the aggregate needs to the aggregate when it needs it.
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
Of course, if the only thing you need is the fields, then you might prefer to work only with that property:
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.