Domain driven design 命名作用类似于ddd构建块（如存储库）的域对象

当在一个领域模型中引入交叉概念时，如果存在一个名称和听起来像对象的东西，但与5个主要DDD构建块之一的责任重叠，那么命名该对象和/或处理实际设计中可能包含或可能不包含该名称或短语的设计的最佳实践是什么实施

为了给出一个更具体的例子，让我们假设我们是本着DDD的精神设计一个时间跟踪应用程序，并且遇到一些领域专家称之为“时间日志”的东西，它应该是记录所有员工的打卡时间和相应的打卡时间的日志

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

现在，我们可以选择将我们的存储库命名为TimeLog，这似乎更符合无处不在语言的DDD概念，或者我们可以将其称为TimeLogEntryRepository，这似乎更符合按照存储库查询/持久化的聚合根命名存储库的一般约定。我更倾向于使用TimeLog，因为它更能描述它在领域模型中扮演的实际角色，这反过来有助于将设计传达给领域专家。另一方面，选择使用TimeGenetryRepository则遵循现有的DDD约定，从而使开发人员更容易遵循设计。一个折衷方案还可以是使用TimeLog命名，但让所有存储库实现一个IRepository接口或从公共存储库基类继承，以帮助开发人员定位存储库类并将其与构成域模型的其他存储库类区分开来。我对使用基类的主要担忧是，它可能会鼓励使用标记接口或不必要的弱基类，这仅仅是为了组织的目的，而不是由于行为因素

---

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

我个人更喜欢

TimeLog

事实上，令人惊讶的是，一旦你把注意力转移到业务而不是技术上，事情就变得容易多了。正确的命名是保持焦点清晰的主要武器

服务也是如此-我使用的不是

ApplicationRegistrationService

，而是

ApplicationRegistrator

---

这是一篇非常好的文章。

我支持@Arnis L.建议。我还要补充一点，关于DDD，您的域应该反映您与业务分析人员和其他非技术人员共享的实际UL（通用语言）。因此，我认为您将与他们讨论

TimeLog

，而不是

TimeLogEntryRepository

。存储库只是一种模式，它的名称不应该出现在命名约定中。

我认为“注册者”或“注册中心”这个词可能更有意义，但在转到googlefight.com后，我惊讶地发现注册者以很大的优势抢走了蛋糕+我读了你链接的文章，结果发现他们提供了一个为存储库本身构建的简洁流畅的界面，非常简洁。我不确定我是否想走那么远，但我能看到它的好处。我同意。您不能命名域中的内容。其他人是这样做的。如果他们称之为“TimeLog”，那么它就是“TimeLog”。模特是怎么回事？代表现实。他们称之为TimeLog，将其建模为TimeLog。相反，TimeGenetryRepository“创造”了一个（虚假的？）现实，而不是“建模”它。DDD就是要在专家的头脑中发现现实。不把技术性的东西强加给商业头脑。旁注：我正在探索（还没有结论）在类图中使用颜色。所有的存储库都是X色，然后TimeLog就是那个颜色。@XaviMontero这里的问题是在域语言中没有“服务”和“存储库”这样的东西。然而，服务和存储库接口存在于域模型中，服务声明了表示某些域概念的方法（而存储库没有）