The purpose of the repository is to provide an adapter around the database. It “knows about the database” so the rest of your code doesn’t have to.

So it seems quite reasonable to me that if you change your database schema, you’ll have to change (or altogether replace) your repositories. The point is that you only have to replace the repositories, because the implementation is hidden from the application by the interface.

If you have lots of aggregates and a repository for each of them, so replacing them wholesale is hard, you might be able to get help from an ORM, depending on the technologies you’re using. A generic Repository<T> seems to be pretty common in C#, for example.

Of course, even if you’re using an ORM, there still has to be some code, somewhere, which knows about the database schema. But this way it’s usually tucked away in an XML mapping file (which of course has its own advantages and disadvantages).

Edit in response to your comments:

I don’t really see what you’re trying to achieve. In your design, it looks like the ‘Hydration’ objects take on the responsibility of communicating with the database and returning a domain object. So if you change your database schema, you still have to change all the Hydration objects. Your proposal does not solve your perceived problem: there has to be some code somewhere which knows about the database schema.

But your design is so much more complicated: there’s an extra layer (the Repository itself) which basically does nothing.

public class FooRepository
{
    private IFooHydration _fooHydration;

    public FooRepository(IFooHydration fooHydration)
    {
        _fooHydration = fooHydration;
    }

    public Foo Get(int id)
    {
        return _fooHydration.Get(id);
    }

    public void Save(Foo entity)
    {
        _fooHydration.Save(entity);
    }
}

It’s much simpler to use an IRepository, and write different implementations of that for your different persistence methods. In short, the Repository is what you plug-in when you change databases.

What you’re talking about here is dependency inversion and encapsulation. You consuming code wants to hold a dependency on some means of getting hold of domain entities, without needing to know how that happens. It wants a set of methods on a black box, which it expects to give some inputs and get some outputs: an interface.

Instead of having your code depend on some concrete implementation of data access, you rely on an abstraction: the interface. So long as your calling code knows only about the abstraction, then it doesn’t matter how you fulfill that interface, so long as you do it correctly.

Taking the Doctrine and raw PDO examples from your question, you might define an interface as:

interface FooRepositoryInterface {
    public function getAFoo($id);
}

With the interface in place, you can implement it in any way you see fit:

public class DoctrineFoo implements FooRepositoryInterface {
    public function __construct(EntityManager $em){ ... }
    public function getAFoo($id){ 
        return $this->em->find("EntityFoo", $id);
    }
}

public class PDOFoo implements FooRepositoryInterface {
    public function __construct(PDO $pdo){ ... }
    public function getAFoo($id){ 
        $pdo->prepare("sql ...");
        $row = $pdo->fetchOne();
        return $this->makeFooFromRow($row);
    }     
}

This allows your other modules to happily depend on data acess in terms of the interface:

class FooBazer {
    public function doBaz(FooRepositoryInterface $repository, $id) {
        $foo = $repository->getAFoo($id);
        $foo->baz();
    }
}