Как проверить из совокупности - PullRequest
0 голосов
/ 24 июня 2019

Я пытаюсь понять валидацию от агрегатной сущности на командной стороне шаблона CQRS при использовании событийного поиска.

В основном я хотел бы знать, каков наилучший способ обработки валидации для: 1. Уникальностискажем код.2. Правильность / проверка идентификатора вечного агрегата.

Мои первые мысли: я думал о конструкторе, передаваемом в сервисе, но это кажется неправильным, так как «Создать» сущности должно быть значением дляназначить.

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

Может кто-нибудь дать мне какое-то руководство здесь?

1 Ответ

1 голос
/ 24 июня 2019

Уникальность скажем кода.

Обеспечение уникальности является конкретным примером проверки правильности набора . Проблема с проверкой набора состоит в том, что, по сути, вы выполняете проверку, блокируя весь набор. Если весь набор включен в один «агрегат», это легко сделать. Но если набор охватывает агрегаты, то это беспорядок.

Распространенным решением для уникальности является управление ею на уровне базы данных; СУБД действительно хороши в операциях над множествами и эффективно сериализуются. К сожалению, это блокирует вас в решении для базы данных с хорошей поддержкой наборов - вы не можете легко переключиться на базу данных документов или хранилище событий.

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

В некоторых случаях вы можете закодировать уникальность кода в идентификатор агрегата. По сути, каждый идентификатор становится набором из одного.

Имейте в виду вопрос Грега Янга

Какое влияние оказывает сбой на бизнес?

Знание того, насколько дорогой сбой, говорит вам о том, сколько вам разрешено тратить на решение проблемы.

Правильность / проверка идентификатора вечного агрегата.

Обычно он состоит из двух частей. Проще всего проверить данные по некоторой согласованной схеме. Если мы согласны с тем, что идентификатор будет URI , тогда я могу подтвердить, что полученные данные удовлетворяют этому ограничению. Аналогично, если предполагается, что идентификатор является строковым представлением UUID, я могу проверить, что полученные данные соответствуют правилам проверки, описанным в RFC 4122 .

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

И, конечно, вы снова можете примирить все расы, присущие распределенным вычислениям.

Магии нет.

...