Список объектов с данными из нескольких ограниченных контекстов

Question

Список объектов с данными из нескольких ограниченных контекстов

Прежде всего, я совсем новичок в DDD, поэтому я могу ошибиться в некоторых понятиях.

Проблема, с которой я сталкиваюсь, заключается в следующем:

У меня есть список билетов для какой-то системы обработки. Билеты основаны на данных из внешних источников, отсканированных / отслеженных Crawlin System.

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

Теперь я хочу создать список билетов со всеми билетами. Каждый тикет имеет некоторые данные из одного ограниченного контекста (доступные действия и т. Д.) И некоторые данные из другого (графическое представление внешних данных).

Я уже знаю, что во избежание дублирования данных я могу использовать составное представление каждого тикета, где каждый ограниченный контекст отображает свои части пользовательского интерфейса. Я видел декомпозицию сайта Amazon. Давайте также предположим, что моя структура шаблонов позволяет мне использовать блоки или компоненты для составления представления заявки.

Эта проблема

Я борюсь с методом извлечения этих частей представления / пользовательского интерфейса в приложении без слишком большого количества запросов. Я не хочу делать один запрос для каждого компонента, чтобы избежать N + 1 запроса ада (даже если эти запросы находятся в некотором кеше NoSQL). Я предполагаю, что мой контроллер представления каким-то образом запрашивает оба ограниченных контекста, чтобы предоставить список элементов управления, а затем отображает их (например, один для получения списка заявок на основе критериев поиска и другой для извлечения внешнего контента на основе списка идентификаторов внешнего контента) , Но я не уверен, что на правильном пути.

Примеры кода на любом языке (псевдо-язык) очень ценятся.

0

composition domain-driven-design php

Решение

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

Других решений пока нет …

Источник

Accepted Answer

Я думаю, что вы на правильном пути.

Так же, как вы написали, вы можете создать какую-то модель представления (сущность представления) для этого с помощью службы, которая будет запрашивать один источник и второй (внешний) источник только один раз. Затем он объединит их в отдельные модели представлений, которые будут переданы на уровень пользовательского интерфейса.

Таким образом, вы также сохраняете логику слияния данных на уровне домена. На уровне представления вы будете работать с ними так же, как с обычными моделями представления (сущностями) — без утечки информации, такой как их источник, способы их объединения и т. Д.

Оказавшись в слое домена, вы также можете добавить локальное кэширование (если требуется).

<?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);

0