Эти описания, как я понимаю, описывают связи между классами. Вроде бы, возражений нет.
Но я не вижу описания взаимосвязи между объектами. Т.е. между какими экземплярами dependentEntity и closureEntity будет устанавливаться связь.
Не совсем так. Для объекта по имени класса можем найти все его потенциальные зависимости. Для каждой зависимости объявлен класс-загрузчик с методом, который по зависимому объекту путем совершения над ним некоторого ритуала (например, просто сравнением полей или выполнением другого SQL-запроса) находит тот объект, от которого наш объект зависит.
Решение довольно универсально.
Думаем над возможностью передавать загрузчику параметры, чтобы не повторяться.
Это универсально, но вынуждает отбирать зависимости квадратичным алгоритмом (на каждый документ-замыкание делается по одному sql запросу).
В том смысле, что будет большая нагрузка на БД? Можно сделать так, чтобы для объектов одного класса замыкания загружались «оптом» (заранее анализировать множество измененных объектов и разделять их по классам). Тогда чтобы получить множество замыканий (по одному правилу), нужно составить хитрый SQL запрос и потом, на стороне репликатора, искать что чему соответствует.
Ну да, хотелось бы именно так. Во всяком случае, когда это возможно. Наверное, не sql, а hql, чтобы сразу получать множество объектов.