Domain driven design 全局值对象

我有一个时间段（上午，下午，晚上等）的一些对象的参考需要。预定的会议，实际的会议

虽然时间段在数据库中具有ID，但它肯定不是实体，因为它不会更改，“AM”时间段在所有对象中都是相同的

我的困难在于知道如何从数据库中检索这个值对象。因为不同的对象可以引用它，所以它不应该是它们的任何存储库方法的一部分，但同时它不应该真正拥有自己的存储库，因为它不是根

那么，您建议如何从数据库中获取该文件

谢谢

更新

---

我赞同eulerfx的回答，因为他解释说句点仍然可以通过存储库从数据库返回，尽管我并不真正喜欢为多个全局值对象设置多个小型存储库的想法。这个区域对我来说还是有点灰色。

因为

时间段

是一个值对象，当其他对象引用它时，它们引用的是值本身，而不是ID。使时间段对象不可变，以便对象一旦引用时间段，就知道它不会更改。时间段值可以存储在数据库表中，然后表记录具有ID，但是这些ID不需要在代码中表示。例如，如果您希望提供一个显示可用时间段列表的UI，则可以使用一个简单的存储库来检索时间段。存储库并不总是必须只返回聚合。如果时间段在本质上是高度静态的，那么你可以考虑缓存在内存中，或者甚至有一个具有所有可用时间周期的静态类。p> 虽然TimePeriod在数据库中有一个ID，但它肯定不是一个实体，因为它不会改变

只要对象具有定义良好的生命周期，即使其内容不变，它也可以是一个实体。要问的问题是“是否会动态创建和删除时段？”

• 是吗？那么TimePeriod应该是一个拥有自己存储库的实体。这是Eric Evans在他的DDD书中描述的一个例子

• 没有？然后，您不需要数据库，只需静态地定义时间段

---

如果它从未更改，为什么不将表硬编码为全局查找？因此，如果我有多个这种类型的查找（例如会议长度），但在数据库中有不同的“ID”类型，我会有一个全局查找服务吗，其中有两种方法是'TimePeriod GetTimePeriods'和'MeetingLength GetMeetingLength'？可能是-这肯定属于“服务”范畴，尽管我不知道这些特定于域的方法是否合适。但问题是Value（lookup）对象的ID可能为Guid或int，而且一个值对象可能比另一个值对象有更多的字段，这使得创建一个通用对象（IValueObjectLookup）变得困难和混乱——否则从服务返回会更好。（如果您在谈论适当性时所指的是返回类型，那么每个valueobject的服务肯定是多余的）。值对象不应该有ID。它的“标识”由它的值定义。“存储库不一定总是只返回聚合。”这不是违背了Evan的概念吗？在他书中关于存储库的章节中，他指出存储库还可以返回摘要计算等。我认为存储库可以根据透视图有多种含义。一些人认为它们只与聚合有关，另一些人认为它们是数据源的更一般的抽象。