Как назвать и реализовать строки набора результатов в DDD?
В DDD у вас есть объект с уникальным идентификатором (ID или UUID). Обычно объект представляет собой хранимую строку в таблице базы данных. Мой репозиторий может загрузить одну сущность (findById) или все сущности одновременно (findAll).
Но теперь нужно написать специальный и очень сложный запрос с соединениями с другими таблицами. Результирующий набор больше не является специальной (пользовательской) сущностью, потому что я выбрал разные поля из нескольких таблиц с псевдонимами и так далее. В зависимости от запроса, результат может не содержать идентификатор.
Я успешно преобразовал эти строки в новую коллекцию объектов, но борюсь с именем (и типом) этой вещи.
Мой вопрос:
Как назвать и классифицировать такие строки из пользовательского запроса в DDD?
Решение
Кажется, вам нужна служба запросов здесь.
DDD очень хорошо сочетается с CQRS, и я считаю, что желаемые результаты доступны только для чтения.
В этом случае вы создаете специальный объект для вашей потребности: UserData, если пользователь содержит некоторые другие отношения, такие как набор ролей, или правильно, вы можете назвать его, например, UserRightsData, и извлечь его из UserQueryService.
Сервисы запросов обычно находятся на уровне приложений.
Если вам нужны результаты, не предназначенные только для чтения, и вместо них простые объекты, которыми вы можете манипулировать и сохранять, тогда вам нужно предоставить нам больше деталей. В частности, вы должны иметь возможность загрузить эту сущность из репозитория, вызвать операцию домена и сохранить ее через службу приложения.
Службы запросов хорошо подходят для представлений, таблиц и отображения данных, с сортировкой, фильтрацией и так далее …
Изменить: Plalx прибил его в ответ на сообщение Эбен Ру.
ProjectName/
IdentityAndAccess/
Application/
Command/
AuthenticateUserCommand.php
ChangeEmailAddressCommand.php
ChangeUserPasswordCommand.php
ChangeUserPersonalNameCommand.php
...
Data/
UserData.php
UserRightsData.php (POPO containing User infos and a list of rights)
RightData.php (Single comment infos)
UserApplicationService.php
UserQueryService.php
Domain/
Model/
Другие решения
Во-первых, вы должны избегать запросов к своей доменной модели, если только вы не следуете определенному агрегату. Даже тогда, в зависимости от вашего дизайна, вы не сможете получить необходимые данные.
Типичная рекомендация состоит в том, чтобы использовать специализированный слой запросов вместе с, возможно, читать модель это представляет необходимые данные. Эта читаемая модель может быть напечатана или свободно, как вам нужно. Например, если список пар имя / значение поможет, возможно, вы выберете тот.
Эти запросы на самом деле не являются частью домена и, как таковые, выходят за рамки доменного дизайна с точки зрения моделирования. Они, однако, важны как часть вашей общей архитектуры / подхода.
Обновить:
В ответ на комментарий @Luca Masera:
Я обычно использую что-то вроде этого (C #) для, скажем, Product:
public interface IProductQuery
{
int ActiveCount();
DataRow Details(Guid id);
Query.Product Get(Guid id);
IEnumerable<Query.Product> Matching(ProductSpecification specification);
}
Query Пространство имен так, что модель чтения Product не мешает моему фактическому домену Product,
В зависимости от моего требования я буду использовать соответствующий возвращаемый объект / структуру / тип.