Инкапсуляция внешнего источника данных в шаблон хранилища

Question

Я создаю проект высокого уровня для новой службы. Сложность службы гарантирует использование DDD (я думаю). Поэтому я сделал обычную вещь и создал службы домена, агрегаты, репозитории и т. Д. Мои репозитории инкапсулируют источник данных. Таким образом, запрос может искать объект в кеше, не получив этого в db, в противном случае вызовет вызов внешней службы для получения требуемой информации . Это довольно стандартно. Теперь аргумент, высказанный моими коллегами, заключается в том, что абстрагирование источника данных так опасно, потому что разработчик, использующий репозиторий, не будет знать о времени, требуемом для выполнения api, и, следовательно, не сможет вычислить время выполнения для любого apis he пишет над ним. Может быть, он хотел бы настроить поведение своего компонента по-разному, если бы знал, что его вызов приведет к вызову REST. Они предлагают мне переместить вызов REST за пределы репозитория и, возможно, даже стратегию кэширования вместе с ним. Я вижу их точку зрения, но вся идея шаблона репозитория заключается в том, чтобы скрыть эту информацию и не иметь в каждом компоненте стратегии кэширования и доступа к данным. Мой вопрос в том, есть ли образец или модель, которая затрагивает эту проблему?

Answer 1

Образец репозитория направлен на уменьшение сцепления с персистирующим слоем. По-моему, я не рискнул бы сделать хранилище настолько полным ответственности.

Вы можете использовать слой Anti Corruption для изменений внешней службы и прокси, чтобы скрыть связанные с кешированием проблемы.

Затем в прикладном уровне я буду кодировать резервную стратегию.

Answer 2

Они предполагают переместить вызов REST вне хранилища

Тогда вы не будете иметь хранилище. Репозиторий означает, что мы не знаем настойчивости подробнее, не то, что мы не знаем, что есть настойчивость. Каждый раз, когда мы используем репозиторий, независимо от его реализации (от списка в памяти до вызова REST), мы ожидаем «медлительность», потому что общеизвестно, что персистенция обычно является узким местом.

Кто-то, кто будет использовать определенную реализацию репозитория (например, на основе REST), будет знать, что он будет обрабатывать ошибки времени ожидания и временные ошибки. Служба, имеющая только зависимость IRepository, все еще знает, что она имеет дело с постоянством.

О стратегиях кэширования вы можете использовать кеширование уровня кэширования и хранилища (кеширование). Вероятно, это должны быть детали реализации.

Теперь аргумент, выдвинутый мои коллеги, что абстрагирования в качестве источника данных таким образом, является опасным, так как разработчик, используя репозиторий не будет знать о время, необходимом для выполнения API и, следовательно, не может быть в состоянии вычислить время выполнения для любого apis, который он пишет над ним. Может быть, он захотел бы настроить поведение своего компонента по-разному, если бы знал, что его вызов приведет к вызову REST.

Это напрасно тратит время, пытаясь усложнить вашу жизнь. Весь смысл абстракции - скрыть грязные детали. В принципе, они предлагают: давайте узнаем о некоторых деталях реализации, чтобы пользователь мог с кодом.

Дело в том, что разработчик должен знать об api, которые они используют.Если компонент использует внешнюю службу (db, веб-сервис), это должно быть известно. Как только вы узнаете, что есть данные для вас, вы знаете, что вам придется подождать.

Если вы идете по маршруту DDD, у вас есть ограниченный контекст (BC). Создание модели, зависящей от другой БК, - это плохая идея . Каждый BC должен публиковать события домена, и каждый заинтересованный BC должен подписаться и сохранить свою собственную модель на основе этих событий. Это означает, что запросы будут «локальными», но вы все равно будете бить db.

Answer 3

Я думаю, что все зависит от того, где вы думаете, какая стратегия выборки/резервного копирования принадлежит, на уровне службы или на уровне инфраструктуры (последний звучит более законно для меня).

Это также может быть сочетание двух - Служба передается упорядоченной серией Хранилищ, чтобы использовать один за другим в случае сбоя. Построение серии РЕПО можно было бы разместить на уровне инфраструктуры или в другом месте. Логическая ошибка в одном месте, резервная конфигурация в другом.

В качестве побочного примечания, асинхронность кажется хорошим способом оповестить пользователей о том, что что-то есть потенциально медленно и будет блокироваться, если вы его ждали. Лучше, чем скрывать все, что связано с ванилью, незаметным названием репозитория и лучше, чем добавление некоторого большого угроза «это может быть медленным» для вашего типа, IMO.