При построении наших моделей чтения при реализации шаблона CQRS, где это возможно, мы хотим создавать плоские, ненормализованные источники данных, которые можно извлекать как можно проще.
Часто система имеет несколько стандартных типов такие как: страны, валюты и т. д. c. это может измениться (новые валюты приходят и go, страны могут изменить названия), хотя относительно редко.
Будете ли вы следовать той же схеме, где каждая модель представления, использующая список этих значений, содержит свой собственный ненормализованный сохраненный список? Или они размещаются отдельно, и запрос извлекает их из отдельного источника данных, который используется всеми представлениями, которым они нужны. ie. нормализовать стандартные типы.
В настоящее время я перешел к нормализованному варианту, но хочу посмотреть, есть ли у кого-нибудь мысли о том, почему это может быть ограничением в будущем?
Обновлено с примерами
Итак, я имею в виду стандартные типы, определенные Воном Верноном в разделе «Реализация доменного дизайна». Иногда это также называют поиском.
Я приведу базовый пример с использованием концепции валют, а затем более сложный сценарий, который, возможно, изменит подход? И поднимает некоторые дополнительные вопросы.
Примечание: это вымышленный вариант использования, поэтому logi c является базовым c и игрушечным.
Сценарий 1 :
У нас есть система заказов, поддерживающая несколько валют. Стандартные типы валют могут находиться в нашем хранилище данных. Хотя потенциально они могут исходить от сторонних сервисов et c.
Модель записи требует только код валюты. Скажите что-то вроде USD, GBP и c.
С точки зрения запроса (для пользовательского интерфейса или отчетности) нам может потребоваться полное имя: «Доллары США» или символ «$».
Итак, у нас есть событие:
class AddedLineItemToOrder:
part
quantity
value
currency (where currency is USD or other)
Это событие обновляет модель представления OrderDetailsView через обработчик событий / ненормализатор.
Теперь, когда мы получим дополнительную информацию о валюте для представления?
- Обработчик / ненормализатор событий может выполнять поиск при обработке события AddedLineItemToOrder и обновлении OrderDetailsView?
Или:
- Обработчик запросов может искать информацию при выполнении запроса GetOrderDetails.
Возможно, с помощью обработчика событий или обработчика запроса использование некоторого сервиса для поиска и получения длинного имени или символа валюты.
Сценарий 2:
Представьте себе другую систему, в которой все заказы изначально в долларах США, и заказ может быть сохранен до того, как он будет оплачен.
Когда дело доходит до оплаты заказа, пользовательский интерфейс позволяет вам выбрать валюту для оплаты. Этот валютный сервис используется моделью чтения сейчас возвращает символ валюты ie. £, а также текущий обменный курс.
В этом сценарии возникает ощущение, что поиск валюты должен произойти при выполнении обработчика запроса, поскольку обменный курс зависит от времени. Клиент может не выбрать заказ в это время и вернуться позже, когда будет другой обменный курс.
Таким образом, когда предоставляемая информация чувствительна ко времени, обработчик запросов должен будет отвечать за объединение этой информации в возвращаемое представление?
- Имеет ли место бизнес-логика c в настоящее время? на стороне чтения? ie. Что общая сумма в национальной валюте рассчитывается до того, как клиенты оплатят заказ. Допустимо ли для какой-либо бизнес-логики c находиться в модели чтения?
- Если у нас была команда PayForOrder, допустимо ли передавать итоговое значение в местной валюте прямо в модель записи, которая будет продолжаться до создать событие OrderPayed, используя это общее значение? ie. Должна ли модель записи повторить этот расчет или она может принять значение, указанное в команде?
- В двух словах: если расчет или преобразование данных происходит в модели чтения и отображается пользователю. Можно ли наивно добавить эти вычисленные или преобразованные значения в команду для отправки на сторону записи?
(Давайте проигнорируем такие вещи, как безопасность и возможность для пользователя, чтобы изменить вычисленные или преобразованные значения с помощью злонамеренных средств).