DDD 建模问题
我的领域中有这两个结构：练习（带有主题、解决方案、难度扩展）和具有名称和父主题的主题。主题是由它的属性定义的，因此从这个意义上来说它是一个值对象， 然而，即使我当前的数据存储与特定主题没有任何关联，该主题的存在仍然可能与该域相关，因此它可以与任何事物无关地存在 - 那么它是一个实体吗？
另一个问题，假设我想要所有具有特定名称的现有主题，是否建议拥有一个SubjectRepository（应该只有聚合根具有关联的存储库）？
I have these two structures in my domain: Exercise (with subjects, solution, difficulty ext.) and Subject which has a name and a father subject. Subject is defined by its attributes so in that sense it's a value object,
However even if my current data store has nothing associated with a particular subject, that subject existence still might be relevant for the domain, so it can exist unrelated to anything- so is it an entity ?
Another question, say I want all existing subjects that have a particular name is it advisable to have a SubjectRepository (should only aggregate roots have associated repositories)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我见过类似的关于 Address 类的 DDD 案例。
从领域来看，属性是有趣的部分，而不是 id。
然而，为了重用和编辑它们，它们需要是没有业务 ID/密钥、只有主 ID/密钥的“实体”。
为了支持 GUI 中的顺利管理，Address 被制作为带有“存储库”的“聚合根”。
你的情况听起来很相似。
I've seen a similar DDD case regarding an Address class.
Domain-wise, the properties were the interesting part, not the id.
However in order to re-use and edit them, they needed to be «entities» with no business id/key, only a primary id/key.
In order to support smooth management in the GUI, Address was made an «aggregate roots» with a «repository».
Your case sounds similar.
如果你需要改变主题并且你有跟踪它的需要，它应该是一个实体。领域中主体的存在在什么意义上是相关的？如果您无法以合理的方式将主题融入到领域中，那么它可能是您需要的服务。
对于你的第二个问题；是的，只拥有聚合根的存储库是明智的。
If you need to change the subject and you have the need to track it, it should be an entity. In what sense is the existence of the subject in the domain relevant? If you can't fit the subject into the domain in a sensible way, it might be a service you need.
To your second question; yes, it's wise to only have repositories for aggregate roots.