Репозиторий “два-в-одном”

Есть некоторый сервис, который дёргает два репозитория (первый - к сущности Order, второй - к сущности OrderPosition) и возвращает уже собранный заказ - Dto объект, в котором лежит и Order и OrderPosition.

public async Task<OderDto> DetailsAsync(int orderId)
{
    var order = await this.OrderRepository.GetAsync(orderId);
    var orderPositions = await this.OrderPositionsRepository.ForOrderAsync(orderId);
    return new OrderDto
    {
       Order = order,
       OrderPosition = orderPositions,
    };
}

Так было устроено приложение, когда оно было собрано на чистом EF - клепаешь себе простенькие Linq-выражения, живёшь не нарадуешься.

Однако когда-то наступает момент, когда некоторые запросы становятся сложными и в приложении появляется Dapper c plain sql запросами. Допустим тот же пример очень хочется переписать избежав двух запросов к базе, всё за раз. И, вместо соединения данных в сервисе прямо в репозитории достаём то, что нам надо:

public async Task<OderDto> GetOderDtoAsync(int orderId)
{
    const string query = @"
        SELECT *
        FROM dbo.Order o
        WHERE 1 = 1
            AND o.Id = @orderId
        SELECT *
        FROM dbo.OrderPosition op
        WHERE 1 = 1
            AND op.OrderId = @orderId
    ";
    var parameters = new
    {
        @orderId = orderId,
    };
    using (var multi = this.Db.QueryMultiple(query, parameters))
    {
        var order = await multi.ReadSingleOrDefaultAsync<Order>();
        var orderPositions = await multi.ReadAsync<OrderPosition>();
        return new OderDto
        {
            Order = order,
            OrderPosition = orderPositions.AsList().AsReadOnly(),
        };
    }
}

(Сервисы конечно в таком подходе редко нужны - только для какой-то сложной обработки выбранных данных, чаще просто излишний слой, тупо передающий данные as is. Но эта экономия числа запросов к базе очень сильно подкупает, да и подобных проблем уже не возникает.)

Вопрос чисто методологический. Можно ли при этом продолжать считать, что используется шаблон Repository или это уже не репозиторий?

У меня так выходит, что это класс совмещает в себе два репозитория и некоторую логику (характерную для сервиса) над возвращёнными объектами, а значит (несмотря на всю дырявость паттерна репозиторий) надо дать ему более подходящее название. Но какое? На что вообще похож данный подход в построении приложения?