4

PROBLEM:

I am pulling in third party data from an XML feed. I need to take that data and convert it into entities.

POINTS FOR DISCUSSION:

My question is how to use Services and Repositories in this case. So, for example, I could create a Service that pulls the data from the feed, and then inject that service into the Repository which could then use it to pull the data and convert it into entities. But I'm not sure if that is the right approach?

The repository could have the logic to pull in the data and then map it to entities, but I don't think the repository should be handling that logic? Or should it?

From a DDD separation of concerns perspective, how should this best be architected?

  • I think it's important to point out that what you're describing as a service here would **not** be considered a domain service in DDD terms. The usual advice of *"services should not be injected into repositories"*, while good advice, doesn't quite apply to this scenario. – MattDavey Jun 16 '13 at 12:07

4 Answers4

5

I could create a Service that pulls the data from the feed, and then inject that service into the Repository.

This would not be considered a domain service in DDD, since it has nothing to do with the domain. It's purely a technical infrastructure concern.

My question is how to use Services and Repositories in this case.

It sounds like you may have two separate concerns here. The repository obviously provides access to the data in the terms of the bounded context, but I'm betting there's some additional data manipulation/transformation going on in between the XML data and your repository...

In DDD terms this would be considered an anti-corruption layer. You have no control over the external data source, and you want to prevent the format of this external data from corrupting the integrity of your carefully designed domain model.

It's ok to inject an anti-corruption layer into a repository - as long as its purpose is well defined as such. This would not be considered a domain service since it has nothing to do with the domain, it's a pure fabrication driven by the nature of the external data source.

MattDavey
  • 8,897
  • 3
  • 31
  • 54
4

No.

Repositories should not have any domain logic what so ever except provinding persistance ignorance.

But the repository itself could have any kind of conversions between the data entities and the domain enteties. It can also use any number of tables or databases to be able to build the requested domain entities.

  • if it's a "service" only used by the repository: Yes
  • If it's a service which is part of the domain: No
MattDavey
  • 8,897
  • 3
  • 31
  • 54
jgauffin
  • 99,844
  • 45
  • 235
  • 372
1

Services should not be injected in the repositories, but the contrary.

If your repository is not tightly coupled to your database (as most implementations seems to be), you could have:

  1. A repository to fetch data from XML;
  2. A service to convert the data to entities;
  3. Another repository to persist new entities;

Another approach: fetch the data and convert to entities in the service layer, and then pass the entities to the repository for persistence.

Luiz Damim
  • 3,803
  • 2
  • 27
  • 31
1

That thing downloading the feed is not a DDD Service. It's a DAO. Yes, the Repository can use any DAO it need to construct the Aggregate. In most cases that DAO is something that your ORM exposes, like ISession in NHibernate or DbSet in Entity Framework, but it can be anything. XML feed reader. Amazon S3 API. A file reader...

Pein
  • 1,216
  • 9
  • 16