当在域模型中传递概念时，存在具有名称和听起来像对象但与5个主要DDD构建块之一的责任重叠的内容，这是命名此对象和/或处理的最佳实践在实际实施中可能包含或不包含该名称或短语的设计？
为了给出一个更具体的例子，我们假设我们正在设计一个DDD精神的时间跟踪应用程序，并遇到域专家称之为“时间日志”的东西，它应该是持有打孔的日志。所有员工的投入和相应的打卡时间。
有了这些信息，我最初的想法是，如果有一个名为TimeLog的类，它允许查询现有的时间条目，并且还用于保存新的或修改的时间日志条目，这样的类实际上扮演DDD存储库的角色。为简单起见，我们假设在经过各种讨论和重构之后，我们得出结论，每次日志条目基本上都是它自己的聚合根，因此需要相应的存储库。
现在我们可以选择将我们的存储库命名为 TimeLog ，这似乎更符合普遍存在的语言的DDD概念，或者我们可以称之为 TimeLogEntryRepository 在他们查询/保留的聚合根之后，似乎符合更常用的命名存储库约定。我更倾向于使用TimeLog的想法，因为它更能描述它在域模型中扮演的实际角色，这反过来又有助于将设计传达给领域专家。另一方面，使用TimeLogEntryRepository的选择遵循现有的DDD约定，因此可以使开发人员更容易理解设计。妥协也可以与TimeLog命名一起使用，但是让所有存储库实现IRepository接口或从公共Repository基类继承，以帮助开发人员找到并区分存储库类与构成域模型的其他类。我使用基类的主要问题是，它可能会鼓励使用标记接口或弱的不必要的基类，仅用于组织目的而不是由于行为因素。
在这种情况下，最佳做法是什么？我可以看到服务可能发生同样类型的问题，因为它们是开发人员通常使用“服务”后缀命名的典型DDD构建块的另一部分，例如在SomeComplexActivityService中，但对于实体和值对象，这实际上是一个非问题。我特别感兴趣的是看看其他人可能会说有更多DDD经验。
答案 0 :(得分：6)
我个人更喜欢TimeLog。
实际上，将焦点转移到业务而不是技术上会变得多么容易。正确的命名是保持焦点锐利的主要武器。
服务也是如此 - 我使用ApplicationRegistrationService代替ApplicationRegistrator。
这是关于repositories的非常好的文章。
答案 1 :(得分：2)
我的第二个@Arnis L.建议。我还要补充一点，对于DDD，您的域名应该反映您与业务分析师和其他非常技术人员共享的实际UL（无处不在的语言）。因此，我认为您将与他们讨论TimeLog而不是TimeLogEntryRepository。存储库只是一种模式，它的名称不应该在命名约定中。