domain-driven-design - 像 ddd 构建 block 一样的域对象的命名，例如存储库

Question

当在域模型中跨越概念时，其中存在具有名称且听起来像对象但与 5 个主要 DDD 构建 block 之一的职责重叠的东西，命名该对象和/或处理设计的最佳实践是什么？在实际实现中可能会或可能不会包含该名称或短语？

举一个更具体的例子，假设我们正在本着 DDD 的精神设计一个时间跟踪应用程序，并且遇到了领域专家称之为“时间日志”的东西，它应该是包含打卡和对应的日志所有员工的打卡时间。

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

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

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

Answer 1

我个人更喜欢TimeLog .

令人惊讶的是，一旦您将重点转移到业务而不是技术上，它变得多么容易。正确的命名是保持专注的主要武器。

服务也是如此 - 而不是 ApplicationRegistrationService , 我用 ApplicationRegistrator .

这是一篇关于 repositories 的不错的文章.