类似于 ddd 构建块（例如存储库）的域对象的命名
当涉及域模型中的概念时，其中存在一些具有名称且听起来像对象的东西，但与 5 个主要 DDD 构建块之一的职责重叠，命名该对象和/或处理设计的最佳实践是什么？在实际实施中可能会或可能不会包含该名称或短语？
举一个更具体的例子，假设我们正在本着 DDD 的精神设计一个时间跟踪应用程序，并遇到了领域专家称为“时间日志”的东西，它应该是保存打卡和相应信息的日志。所有员工的下班时间。
有了这些信息，我最初的想法是，如果有一个名为 TimeLog 的类，它允许查询现有的时间条目，并且还可以保存新的或修改的时间日志条目，那么这样的类确实扮演了 DDD 存储库的角色。为了简单起见，我们假设经过各种讨论和重构，我们得出的结论是，每次日志条目本质上都是它自己的聚合根，因此需要相应的存储库。
现在我们可以选择将存储库命名为 TimeLog ，这似乎更符合通用语言的 DDD 概念，或者我们可以将其命名为 TimeLogEntryRepository ，这似乎更合适在它们查询/持久化的聚合根之后命名存储库的更通用约定。我更倾向于使用 TimeLog 的想法，因为它更能描述它在领域模型中扮演的实际角色，这反过来又有助于将设计传达给领域专家。另一方面，选择使用 TimeLogEntryRepository 遵循现有的 DDD 约定，因此将使开发人员更容易遵循设计。折衷方案还可以是采用 TimeLog 命名，但让所有存储库实现 IRepository 接口或从公共存储库基类继承，以帮助开发人员找到存储库类并将其与构成域模型的其他存储库类区分开来。我对使用基类的主要担忧是，它可能会鼓励使用标记接口或弱不必要的基类，只是为了组织目的而不是由于行为因素。
在这种情况下，最佳做法是什么？我可以看到服务可能会发生相同类型的问题，因为它们是典型 DDD 构建块的另一部分，开发人员通常使用“服务”后缀命名，例如 SomeComplexActivityService，但对于实体和值对象来说，这实际上不是问题。我特别有兴趣了解其他拥有更多 DDD 经验的人可能会说些什么。
When comming accross concepts within a Domain Model where there exists something that has a name and sounds like an object but overlaps with the responsiblility of one of the 5 main DDD building blocks what is the best practice for naming this object and or dealing with design which may or may not include that name or phrase in the actual implementation?
To give a more concrete example lets say that we are designing a time tracking application in the spirit of DDD and encounter something that the domain experts refer to as a "time log" which is supposed to be the log which holds punch-in and corresponding punch-out times for all employees.
With this information my initial thought is that if there were a class written called TimeLog which allowed for querying existing time entries and also for persisting new or amended time log entries that such a class is really playing the role of a DDD repository. For simplicity sake, lets assume that after various discussions and refactoring that we come to a conclusion that each time log entry is essentially it's own aggregate root and thus has the need for a corresponding repository.
Now we are left with the option of either naming our repository as TimeLog which seems more in line with the DDD concept of ubiquitous language or we could call it TimeLogEntryRepository which seems to fit the more general convention for naming Repositories after the Aggregate root that they query/persist. I'm leaning more towards the the idea of using TimeLog since it is more descriptive of the actual role that it plays in the domain model which should in turn help in communicating design to domain experts. The choice of using TimeLogEntryRepository on the other hand follows existing DDD conventions and thus would make the design easier to follow for developers. A compromise could also be to go with the TimeLog naming but to have all repositories implement an IRepository interface or inherit from a common Repository base class to help developers locate and distinguish repository classes from others that make up the domain model. The main concern I have with using a base class is that it may encourage the use of marker interfaces or a weak unnecessary base class just for the purpose of organization and not due to behavioral factors.
What is the best practice in cases like this? I can see the same type of issue perhaps happening for services as they are another piece of the typical DDD building blocks that developers typically name using a "Service" suffix such as in SomeComplexActivityService but for Entities and Value Objects this is really a non-issue. I'm especially interested to see what others may have to say that have more DDD experience under their belt.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我个人更喜欢
TimeLog。事实上，一旦你将注意力转向业务而不是技术，事情就会变得容易得多，这真是令人惊讶。正确的命名是保持焦点清晰的主要武器。
服务也是如此 - 我使用
ApplicationRegistrator，而不是ApplicationRegistrationService。这是一篇关于存储库的非常好的文章。
I personally prefer
TimeLog.It's actually amazing how much easier it becomes once you switch focus to business instead of technology. Proper naming is main weapon to keep that focus sharp.
The same goes for services - instead of
ApplicationRegistrationService, I useApplicationRegistrator.Here's quite nice article about repositories.
我同意@Arnis L.的建议。我还要补充一点，对于 DDD，您的域应该反映您与业务分析人员和其他通常是非技术人员的人员共享的实际 UL（通用语言）。因此，我认为您会与他们讨论
TimeLog而不是TimeLogEntryRepository。存储库只是一种模式，它的名称不应该出现在命名约定中。I second @Arnis L. suggestion. I would also add that in respect to DDD your domain should reflect the actual UL (Ubiquitous Language) which you share with business analysist and other people that are often non technical people. So I think that you will talk with them about
TimeLogand notTimeLogEntryRepository. Repository is just a pattern and it's name should not be in the naming conventions.