大佬教程收集整理的这篇文章主要介绍了domain-driven-design – 域对象的命名,其作用类似于ddd构建块,例如存储库，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
为了给出一个更具体的例子,我们假设我们正在设计一个DDD精神的时间跟踪应用程序,并遇到域专家称之为“时间日志”的东西,它应该是保存插入和对应的日志.所有员工的打卡时间.
有了这些信息,我最初的想法是,如果有一个名为TimeLog的类,它允许查询现有的时间条目,并且还用于保存新的或修改的时间日志条目,这样的类实际上正在扮演DDD存储库的角色.为简单起见,我们假设在经过各种讨论和重构之后,我们得出结论,每次日志条目本质上都是它自己的聚合根,因此需要相应的存储库.
现在我们可以选择将我们的存储库命名为TimeLog,这似乎更符合普遍存在的语言的DDD概念,或者我们可以将其称为TimeLogEntryRepository,它似乎符合在查询聚合根之后命名存储库的更一般惯例/坚持.我更倾向于使用TimeLog的想法,因为它更能描述它在领域模型中扮演的实际角色,这反过来有助于将设计传达给领域专家.另一方面,使用TimeLogEntryRepository的选择遵循现有的DDD约定,因此可以使开发人员更容易理解设计.妥协也可以与TimeLog命名一起使用,但是让所有存储库实现IRepository接口或从公共Repository基类继承,以帮助开发人员定位和区分存储库类与构成域模型的其他类.我使用基类的主要问题是它可能鼓励使用标记接口或弱的不必要的基类只是为了组织而不是由于行为因素.
在这种情况下,最佳做法是什么？我可以看到服务可能发生的相同类型的问题,因为它们是开发人员通常使用“服务”后缀命名的典型DDD构建块的另一部分,例如在someComplexActivityservice中,但对于实体和值对象,这实际上是一个非问题.我特别感兴趣的是看看其他人可能会说有更多DDD经验.
实际上,一旦您将重点转向业务而非技术,它变得更加容易.正确的命名是保持焦点锐利的主要武器.
服务也是如此 – 我使用ApplicationRegistrator而不是ApplicationRegistrationservice.
这是关于repositories的非常好的文章.
以上是大佬教程为你收集整理的domain-driven-design – 域对象的命名,其作用类似于ddd构建块,例如存储库全部内容，希望文章能够帮你解决domain-driven-design – 域对象的命名,其作用类似于ddd构建块,例如存储库所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。