Список объектов с данными из нескольких ограниченных контекстов
Прежде всего, я совсем новичок в DDD, поэтому я могу ошибиться в некоторых понятиях.
Проблема, с которой я сталкиваюсь, заключается в следующем:
У меня есть список билетов для какой-то системы обработки. Билеты основаны на данных из внешних источников, отсканированных / отслеженных Crawlin System.
Очевидно, что эти два являются отдельными ограниченными контекстами. На данный момент я совершенно уверен, что мои границы здесь верны, так как они имеют мало общих черт (билет связан с внешним источником, но они обрабатываются и обновляются отдельно и разными способами).
Теперь я хочу создать список билетов со всеми билетами. Каждый тикет имеет некоторые данные из одного ограниченного контекста (доступные действия и т. Д.) И некоторые данные из другого (графическое представление внешних данных).
Я уже знаю, что во избежание дублирования данных я могу использовать составное представление каждого тикета, где каждый ограниченный контекст отображает свои части пользовательского интерфейса. Я видел декомпозицию сайта Amazon. Давайте также предположим, что моя структура шаблонов позволяет мне использовать блоки или компоненты для составления представления заявки.
Эта проблема
Я борюсь с методом извлечения этих частей представления / пользовательского интерфейса в приложении без слишком большого количества запросов. Я не хочу делать один запрос для каждого компонента, чтобы избежать N + 1 запроса ада (даже если эти запросы находятся в некотором кеше NoSQL). Я предполагаю, что мой контроллер представления каким-то образом запрашивает оба ограниченных контекста, чтобы предоставить список элементов управления, а затем отображает их (например, один для получения списка заявок на основе критериев поиска и другой для извлечения внешнего контента на основе списка идентификаторов внешнего контента) , Но я не уверен, что на правильном пути.
Примеры кода на любом языке (псевдо-язык) очень ценятся.
Решение
Я думаю, что вы на правильном пути.
Так же, как вы написали, вы можете создать какую-то модель представления (сущность представления) для этого с помощью службы, которая будет запрашивать один источник и второй (внешний) источник только один раз. Затем он объединит их в отдельные модели представлений, которые будут переданы на уровень пользовательского интерфейса.
Таким образом, вы также сохраняете логику слияния данных на уровне домена. На уровне представления вы будете работать с ними так же, как с обычными моделями представления (сущностями) — без утечки информации, такой как их источник, способы их объединения и т. Д.
Оказавшись в слое домена, вы также можете добавить локальное кэширование (если требуется).
<?php
class ViewTicketProvider
{
private $externalService;
public function __construct(ExternalProviderInterface $externalService)
{
$this->externalService = $externalService;
}
public function getViewTickets(Collection $tickets)
{
$ids = $tickets->getIds();
$externalEntities = $this->externalService->getByIds($ids);
$viewTickets = array();
foreach ($tickets as $ticket) {
$viewTicket = new ViewTicket($ticket);
// If this is too complex, use another service for the merging.
$viewTicket->addMoreInfoFromExternalSource($externalEntities);
$viewTickets[] = $viewTicket;
}
return $viewTickets;
}
}$ticketRepo = new TicketRepository();
$externalService = new ExternalService();
$tickets = $ticketRepo->getTicketsBasedOnSomeCriteria($criteria);
$viewTicketProvider = new ViewTicketProvider($externalService);
$viewTickets = $viewTicketProvider->getViewTickets($tickets);
Другие решения
Других решений пока нет …