Service DDD使用存储库中的服务

问题:

我正在从XML提要中提取第三方数据。我需要把数据转换成实体

讨论要点：

我的问题是在这种情况下如何使用服务和存储库。例如，我可以创建一个从提要中提取数据的服务，然后将该服务注入存储库，存储库可以使用它提取数据并将其转换为实体。但我不确定这是不是正确的方法

存储库可以有逻辑来拉入数据，然后将其映射到实体，但我认为存储库不应该处理这种逻辑？还是应该

---

从DDD关注点分离的角度来看，应该如何最好地进行架构？

不应该将服务注入到存储库中，相反

如果您的存储库没有与数据库紧密耦合（大多数实现似乎都是这样），那么您可以：

从XML获取数据的存储库

将数据转换为实体的服务

另一个保存新实体的存储库 另一种方法是：获取数据并将其转换为服务层中的实体，然后将实体传递到存储库以进行持久化。

否

存储库不应该有任何域逻辑，除非提供持久性

但是存储库本身可以在数据实体和域实体之间进行任何类型的转换。它还可以使用任意数量的表或数据库来构建请求的域实体

• 如果它是仅由存储库使用的“服务”：Yes
• 如果是属于域的服务：No

---

下载提要不是DDD服务。这是一把刀。是的，存储库可以使用构建聚合所需的任何DAO。在大多数情况下，DAO是ORM公开的东西，比如NHibernate中的ISession或实体框架中的DbSet，但它可以是任何东西。XML提要阅读器。AmazonS3API。文件阅读器
我可以创建一个从提要中提取数据的服务，然后将该服务注入存储库
在DDD中，这不会被视为域服务，因为它与域无关。这纯粹是一个技术基础设施问题
我的问题是在这种情况下如何使用服务和存储库
听起来你可能有两个不同的关注点。存储库显然提供了对有界上下文中的数据的访问，但我打赌在XML数据和存储库之间会有一些额外的数据操作/转换
在DDD术语中，这将被视为反腐败层。您无法控制外部数据源，并且希望防止此外部数据的格式破坏精心设计的域模型的完整性

---

在存储库中注入一个反腐败层是可以的，只要它的目的定义得很好。这不会被视为域服务，因为它与域无关，它纯粹是由外部数据源的性质驱动的虚构。
我认为有必要指出，您在这里描述的服务不会被视为DDD术语中的域服务。“不应将服务注入存储库”这一常见建议虽然是好建议，但并不完全适用于这种情况。+1区分域服务和技术基础设施是很重要的。