0

I haven't found anything concrete on the topic from the gurus, except

There are other ways to implement an Anticorruption Layer, such as by means of a Repository (12). However, since Repositories are typically used to persist and reconstitute Aggregates, creating Value Objects by that means seems misplaced. If our goal is to produce an Aggregate from an Anticorrup- tion Layer, a Repository may be a more natural source.

from Vernon Vaughn.

What my concern is that mostly ORMs/queries are used as examples of Repositories in the DDD literature. My project is very scarce in domain logic cause it's mainly a wrapper on a couple of APIs and combines the outcome of those Contexts. The responsibilities of the project are broad and could fit many areas/contexts of the business as a whole. The only architectural rule forced from the beginning is the onion architecture and at least the DDD technical modeling concepts seem fitting for me. I must say it's hard to reason about the domain in this particular ongoing project.

Tomasz Szymanek
  • 253
  • 2
  • 5
  • 15

3 Answers3

2

Does an external service (API) fit the DDD definition of a Repository?

Maybe?

REPOSITORIES address the middle and end of the [domain object's] life cycle, providing the means of finding and retrieving persistent objects while encapsulating the immense infrastructure involved.

Repository is a pattern, motivated by the notion of separation of concerns -- you shouldn't have to fuss with the details of persistence when you are working on the domain logic.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
1

DDD is about the domain only. Details of how your app persists entities are not of its concern. That's the reason why you define the interface (in the case of .NET) of your repository in your domain, but the actual implementation is part of the infrastructure of your code.

Repositories are nothing but a pattern for you to do "CRUD" operations on an entity without the concerns of how is done. Remember that your client class (the one using the repository) can only see the exposed public methods. Whatever happens inside, it's a mystery :)

DDD says, give me an interface for me to operate. How you do it, that's your problem. You can effectively persist your entities using an external API (think of Twitter API), a text file, ORM (direct connection to a database). DDD doesn't care.

Pepito Fernandez
  • 2,352
  • 6
  • 32
  • 47
0

take a modern JavaScript website as an example. You'll have plenty of REST calls to create/find/update/delete your domain objects.

In the case of a server application, you'll have a database and a DAO implementation as a client interface to your database. In your web application, you'll also have some REST-client functionality as client interface to your server application. Both are considered repositories, no matter if the implemenentation of the client interface access data in your database / your server / your file sytem etc.

EasterBunnyBugSmasher
  • 1,507
  • 2
  • 15
  • 34