Загрузка данных для проверки бизнес-правила с помощью CQRS и Event Sourcing

Question

У меня есть команда CreateItem, которая имеет имя создаваемого элемента (совокупного корня). Теперь у меня есть бизнес-правило, в котором говорится, что все элементы должны быть однозначно названы.

Если я использую источники событий, нет способа посмотреть это из модели записи, поэтому мне нужно иметь что-то, что я думаю, называется проекцией, которая будет таблицей, которая содержит имена каждого «Пункт», который будет обновляться на основе события ItemCreated.

Теперь это нормально для кода, который обрабатывает команду CreateItem, чтобы проверить эту таблицу (и это должно быть сделано с запросом?). С возможной согласованностью вполне возможно, что эти данные будут устаревшими, так как мне это нужно?

Answer 1

Теперь у меня есть бизнес-правило, говорит, что все элементы должны быть уникальными именами

Вы вошли в проблемное пространство называют заданной проверки. Это означает, что вам нужно прочитать это эссе на Greg Young, прежде чем что-либо сделать.

С возможной согласованностью эти данные могут быть устаревшими, поэтому как мне это с этим справиться?

Есть только три ответы, которые я знаю о

Accept возможной последовательности, который должен сказать, изменить требование. Часть обещания ddd (откуда и происходит «совокупный корень») заключается в том, что вы не только выравниваете модель с бизнесом, но также имеете стратегию разделения реальных требований от воображаемых и изучения альтернативных реализаций - не только модели, но и самого бизнеса.

Для ограничений уникальности - если совокупность добросовестно пытается проверить уникальность, и у вас есть процесс, позволяющий сообщать о дублировании (на основе чтения потоков событий) и разумную стратегию смягчения, когда появляется дубликат, действительно ли важно, чтобы модель отвергала все дублированные имена?

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

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

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

Меняйте агрегатную границу Если вам нужна согласованность транзакций в наборе, то множество является частью модели предметной области, и должно быть представлены в границе некоторой совокупности - для например, «ItemCatalog» возможно. Исследование на вездесущем языке экспертами по домену может помочь обнаружить новый агрегат, который отвечает за это ограничение.

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

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