命名像ddd构建块（如存储库）的域对象

Question

当在域模型中提交概念时，存在具有名称并且听起来像对象但与5个主DDD建筑之一的责任重叠的概念阻止命名该对象的最佳做法是什么，或者处理可能包含或可能不包含该名称或短语的设计？

举一个更具体的例子，可以说我们正在设计一个DDD精神的时间跟踪应用程序，并遇到一些领域专家称之为“时间日志”的东西，该日志应该是持有冲头的日志并为所有员工提供相应的打卡时间。

有了这些信息，我最初的想法是，如果有一个名为TimeLog的类可以查询现有的时间条目，并且还可以保留新的或修改的时间日志条目，这样的类实际上扮演着DDD存储库的角色。为了简单起见，让我们假设在经过各种讨论和重构之后，我们得出结论：每次日志条目本质上都是自己的聚合根，因此需要相应的存储库。

现在我们只剩下两种命名我们的资源库为TimeLog的，这似乎更符合通用语言或的DDD概念行选项，我们可以把它叫做TimeLogEntryRepository这似乎符合更一般的惯例命名它们查询/保留的聚合根之后的存储库。我更倾向于使用TimeLog的想法，因为它更多地描述了它在域模型中扮演的实际角色，这反过来又有助于将设计传达给域专家。另一方面，使用TimeLogEntryRepository的选择遵循现有的DDD约定，因此会使开发人员更易于遵循设计。妥协也可能与TimeLog命名一致，但要让所有存储库实现IRepository接口或从公共Repository基类继承，以帮助开发人员定位和区分构成域模型的其他人的存储库类。我使用基类时主要关心的是，它可能会鼓励使用标记接口或弱的不必要的基类，只是为了组织目的而不是因为行为因素。

这种情况下的最佳做法是什么？我可以看到服务可能发生的相同类型的问题，因为它们是开发人员通常使用诸如SomeComplexActivityService中的“服务”后缀命名的另一块典型的DDD构建块，但对于实体和值对象而言，这实际上是非问题。我特别感兴趣的是看看其他人可能不得不说，他们有更多的DDD经验。

Answer 1

我个人比较喜欢TimeLog。

事实上，一旦您将注意力转向业务而非技术，它会变得多么容易。正确的命名是保持焦点锐利的主要武器。

同样的服务 - 而不是ApplicationRegistrationService，我使用ApplicationRegistrator。

这里是关于repositories的相当不错的文章。

Answer 2

我第二@Arnis L.的建议。我还想补充一点，就DDD而言，您的域名应该反映您与业务分析师和其他非技术人员分享的实际UL（无处不在的语言）。所以我认为你会和他们谈谈TimeLog而不是TimeLogEntryRepository。存储库只是一个模式，它的名字不应该在命名约定中。