Где проверить уникальные свойства AggregateRoot? - PullRequest
0 голосов
/ 08 июля 2019

У меня есть «большой» набор AggregateRoots со свойством, которое должно быть уникальным в своем контексте. Но где я могу это проверить? Я думаю, это зависит от контекста, и, как я вижу, у меня есть два варианта:

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

Или я перемещаю «уникальный индекс» внутри другого агрегата как словарь ссылок на агрегат и позволяю этому словарю проверять уникальные свойства. Поскольку у меня очень большой набор AR, этот подход может быть проблематичным, если он не реализован, так что индекс может храниться на диске в максимально возможной степени.

Но есть ли здесь настоящий победитель? Являются ли оба метода действительными и безопасными для использования? Какие основные недостатки нужно учитывать? Другие варианты?

Мои мысли:

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

1 Ответ

0 голосов
/ 10 июля 2019

Агрегат заботится только о своей последовательности. На самом деле его не интересует, как это соотносится или относится к чему-либо еще в системе, за ее пределами.

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

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

...