jpi*_*son 8 domain-driven-design naming-conventions ddd-repositories
当在域模型中传递概念时,存在具有名称和听起来像对象但与5个主要DDD构件块之一的责任重叠的内容,这是命名此对象和/或处理设计的最佳实践.在实际实施中可能包括也可能不包含该名称或短语？
为了给出一个更具体的例子,我们假设我们正在设计一个DDD精神的时间跟踪应用程序,并遇到域专家称之为"时间日志"的东西,它应该是保存插入和对应的日志.所有员工的打卡时间.
有了这些信息,我最初的想法是,如果有一个名为TimeLog的类,它允许查询现有的时间条目,并且还用于保存新的或修改的时间日志条目,这样的类实际上正在扮演DDD存储库的角色.为简单起见,我们假设在经过各种讨论和重构之后,我们得出结论,每次日志条目本质上都是它自己的聚合根,因此需要相应的存储库.
现在我们可以选择将我们的存储库命名为TimeLog,这似乎更符合普遍存在的语言的DDD概念,或者我们可以将其称为TimeLogEntryRepository,它似乎符合在查询聚合根之后命名存储库的更一般惯例/坚持.我更倾向于使用TimeLog的想法,因为它更能描述它在域模型中扮演的实际角色,这反过来又有助于将设计传达给领域专家.另一方面,使用TimeLogEntryRepository的选择遵循现有的DDD约定,因此可以使开发人员更容易理解设计.妥协也可以与TimeLog命名一起使用,但是让所有存储库实现IRepository接口或从公共Repository基类继承,以帮助开发人员找到并区分存储库类与构成域模型的其他类.我使用基类的主要问题是它可能鼓励使用标记接口或弱的不必要的基类只是为了组织而不是由于行为因素.
在这种情况下,最佳做法是什么？我可以看到服务可能发生同样类型的问题,因为它们是开发人员通常使用"服务"后缀命名的典型DDD构建块的另一部分,例如在SomeComplexActivityService中,但对于实体和值对象,这实际上是一个非问题.我特别感兴趣的是看看其他人可能会说具有更多DDD经验的东西.