Как спроектировать репозиторий, если источник данных отличается в зависимости от операций DML / READ?

Question

Мы запускаем наше новое приложение, в котором мы используем базу данных SQL Server для всех наших вставки / обновления / удаления / выбора, т.е. и SELECT, и операции DML.

Но скоро у нас будет два разных источника: SQL Server и Elastic Search. Идея состоит в том, чтобы выполнить все операции DML в базе данных SQL Server, но мы будем использовать Elastic Search для ВСЕХ операций выборки (выбора).

Данные реплицируются в ES из базы данных SQL Server.

В настоящее время структура нашего проекта выглядит примерно так:

Контроллер (уровень пользовательского интерфейса)

CreateStock(Stock stock) {
    _serviceLayer.CreateStock(stock);
}

List<Stock> GetStocks() {
    var stocks =  _serviceLayer.GetStocks()  
}

Уровень обслуживания:

CreateStock(Stock stock) {
    // business logic
    _repository.CreateStock(stock)
}

List<Stock> GetStocks() {
    return _repository.GetStocks(stock)  
}

Репозиторий:

CreateStock(Stock) {
    // Insert data into SQL Server database with ADO.NET
}

List<Stock> GetStocks() {
    // Get data from SQL Server database with ADO.NET
}

Будущие требования:

Репозиторий:

CreateStock(Stock) {
     // Insert data into SQL Server database with ADO.NET
}

List<Stock> GetStocks() {
     // Get data from other data source (ElasticSearch)
}

Теперь, конечноЯ мог бы создать совершенно новые классы репозитория для новой реализации с ElasticSearch в качестве источника данных. Оба хранилища будут наследоваться от общего интерфейса. Но проблема с этим подходом заключается в том, что я буду дублировать операции DML в обоих классах.

Как я могу использовать код DML в будущем?

1. Должен ли я создать два репозитория? Один для DML, а другой для SELECT? Таким образом, я мог бы создать одну реализацию для репозитория DML и две реализации для SELECT репозитория?

2. Должен ли я создать один репозиторий, а затем добавить еще один после этого?

Есть ли вариант 3?

Возможно, мы решим использовать базу данных SQL Server для DML и чтения, когда Elastic Search не работает в течение нескольких дней.