Рабочий процесс разработки, рефакторинг и инструменты

Question

При работе с классическим постоянством "Текущее состояние" мы можем добавить новое свойство к сущности. Например, при использовании сценария " Блог" существует много постов, мы можем добавить свойство "Рейтинг" к сущности поста. Мы хотим установить значение рейтинга по умолчанию равным 3, поэтому при добавлении столбца в БД значение по умолчанию устанавливается равным 3.

В CQRS я прочитал, что одна стратегия для этого - установить значение по умолчанию в конструкторе (Rating = 3), поэтому при воспроизведении из событий будет доступно значение по умолчанию, если нет явного события, которое изменяет значение рейтинга. Это не кажется мне хорошим решением, так как событие не создается, и поэтому модель чтения (или другие менеджеры процессов / BC) не будет учитывать значение по умолчанию. (может быть здесь не так?)

Следовательно, может показаться логичным, что при добавлении нового свойства в агрегат должна быть выдана команда для каждого "экземпляра" этого типа агрегата, устанавливающего значение по умолчанию, которое, в свою очередь, создает требуемые события - например, обновляется модель чтения и т. Д. процессы / BC могут потреблять и обрабатывать события. Может быть, я далеко на этом?

Я не нашел много информации об инструментах с NEventStore, поэтому мне интересно, какие стратегии используются?

Одна стратегия, о которой я могу подумать, заключается в том, что для каждого "релиза" необходимо создавать одноразовый исполняемый файл / скрипт, который будет:

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

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

Универсальный инструмент был бы полезен, если бы можно было "производить" события для всех потоков данного агрегатного типа.

Какие стратегии используют другие для обработки подобных изменений в домене?

Что касается #1 - я не верю, что есть функция GetAllStreams в EventStore или в любом случае для сопоставления StreamId с типом агрегата, поэтому я вижу единственный способ получить все агрегаты (идентификаторы потока) данного типа, это запрос из модели чтения? Если бы нужно было создать "универсальный инструмент", чтобы помочь с этим, этот инструмент должен был бы знать схему считываемой модели, чтобы получить список идентификаторов потоков, что сделало бы его гораздо менее "универсальным"