【问题标题】:Use Infrastructure service or Repository in Entity在实体中使用基础设施服务或存储库
【发布时间】:2014-10-14 12:39:13
【问题描述】:

我有一个实体,Exchange。 Exchange 需要在启动时填充 VO 列表 CurrencyPair。 CurrencyPair 的集合作为主数据存储在数据库中,并有一个名为 ICurrencyPairRepository 的存储库来获取所有可用的货币对。所以我想在应用启动后在 Exchange 实体中获取 CurrencyPair 集合。

我的问题是,我可以直接将 ICurrencyPairRepsoitory 的实现注入到 Exchange 中吗?还是应该有一个从存储库中获取 CurrencyPairs 的基础设施服务实现?(当然,ICurrencyPairRepository 接口在域层内部,它的实现在基础设施层)

或者我应该在 Exchange 中注入应用程序服务吗?我们是否允许仅将域服务注入实体,或者也可以注入其他服务/存储库?

用例:

在启动时,交易所需要获取应用程序中所有允许交易的货币对。每当有新订单进入交易所时,它都会包含它想要交易的货币对。交易所随后需要检查该货币对是否允许交易。如果是,则转发订单,否则,丢弃请求。

由于 Exchange 是聚合根,我可以从应用程序启动的位置对其进行初始化,并为其提供一组货币对,但我很想知道允许在也是聚合根的实体中注入什么在这种情况下。

【问题讨论】:

  • 一般情况下,不建议向任何实体注入服务/存储库。您也可以发布您的用例吗?
  • Hippoom 评论的原因是向实体添加服务和存储库会使创建和重构实体变得更加困难,并且使其行为更难理解。如果您可以举一个Exchange 中使用CurrencyPair 集合的方法的示例,这将对您的问题有所帮助。
  • @WaqasShah 请查看 DDD 中值对象、存储库和应用程序服务的定义。从您的问题来看,它们可能不是您认为的那样。聚合的概念也可以提供帮助。
  • 我已经提供了用例,请查看。另外,我确实了解 VO、应用程序服务和存储库,但我只想了解在使用实体与服务时限制我们的边界。谢谢
  • 实体很少需要使用服务,因为它们通常在自己的聚合(以其他实体和 VO 的形式)中拥有它们持久需要的所有东西,并且它们偶尔需要作为方法参数传递给它们.域对象无法引用应用程序服务,因为它们位于不同的、无法访问的层中。

标签: domain-driven-design ddd-repositories ddd-service


【解决方案1】:

对于某些人来说,将存储库依赖项直接注入实体是可以接受的,我个人非常不喜欢这种解决方案。当您同时处理基础架构(违反 SRP)时,很难将注意力集中在行为上。

我通常尝试做的是检索实体所需的全部信息的应用程序服务......然后我对测试和编写行为非常满意。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2021-01-08
    • 2010-11-25
    • 1970-01-01
    • 2013-09-19
    • 2019-03-05
    • 1970-01-01
    • 2018-03-26
    相关资源
    最近更新 更多