подсчет общего количества элементов ресурса (отдельный запрос к коллекции)

Question

подсчет общего количества элементов ресурса (отдельный запрос к коллекции)

Я пытаюсь найти лучший способ получить общее количество предметов при возврате коллекции ресурсов. Я думаю о двух подходах, просто хочу узнать ваше мнение о том, что лучше?

сценарий:

пользователь хочет получить список 10 автомобили из моего 10000 автомобили с некоторыми курсорами, такими как (ограничение, до, после, фильтры и т. д.)

Опция 1:

class VehiclesRepo()
{
function getVehicles(){
// get 10000 vehicles with one query; : returns collection
// return 10000 vehicles and do filtration on transformation layer to keep total_count of vehicles
}
}

вариант 2:

class VehiclesRepo()
{
function getVehicles(){
// get 10 vehicles with one query including filtration; : returns collection
// return 10 vehicles, and do another query for total_count
}
}

пожалуйста, рассмотрите влияние операции на память, круги процессора? также моя система полностью DDD, так что я пытаюсь не иметь утечки домена

0

domain-driven-design mongodb performance php transformation

Решение

Другие решения

я пытаюсь сделать это без необходимости доступа к уровню инфраструктуры
извне домена

Это на самом деле ваша проблема. Агрегаты DDD предназначены для обработки команд, согласованности транзакций и бизнес-инвариантов, а не для запросов.

Вот почему CQRS так популярен в наши дни. Я настоятельно рекомендую вам не полагаться на модель вашего домена для запросов.

2

Источник

Accepted Answer

Оба варианта в принципе хороши, но я думаю, что с 10 000 автомобилей у вас уже есть проблемы с производительностью, если вы используете вариант 1. Поэтому я бы выбрал вариант 2.

Но, возможно, есть еще одна проблема с вашим дизайном:

Я пытаюсь сделать это без необходимости доступа к уровню инфраструктуры извне домена.

Этот комментарий предполагает, что у вас есть следующие слои:

 Application
⇣
Domain
⇣
Infrastructure

Если вы не используете какой-то Принцип обращения зависимости это фактически делает инфраструктуру зависимой от уровня домена, тогда у вас есть проблемы с этим дизайном. Домен должен быть максимально чистым. Если домен зависит от инфраструктуры, это означает, что вы не можете использовать свою модель домена независимо от инфраструктуры. Это плохо, потому что инфраструктура — это искусственная вещь, которой нет в реальном мире вашего домена.

Итак, что вы должны сделать концептуально это:

Application
⇣     ⇣
⇣    Infrastructure
⇣    ⇣
Domain

Тогда ваши реализации репозитория станут естественными и позволят выполнять операции запроса, например:

Дайте мне автомобиль с удостоверением личности X
Дайте мне все автомобили с колесами больше Y
Дайте мне все транспортные средства, которые соответствуют фильтру Z

Обратите внимание, что эти операции запроса должны возвращать реальные бизнес-объекты, а не DTO, строки базы данных или тому подобное.

Если вы хотите узнать больше о плюсах и минусах различных архитектур с DDD, я предлагаю вам прочитать главу «Архитектура» в Реализация DDD Вон Вернон.

Примечание к ответу @ plaxl: Ответ относится только к CQRS, который вы не упоминаете в своем вопросе одним словом. Таким образом, вне контекста CQRS, использование модели домена для операций с запросами совершенно нормально.

1