Управление версиями
Если бы Ваши изменения событий Вы создали бы новую версию того события и сохранили бы старые. Для хранения доменной формы кода, чрезмерно увеличенной в размере с обработкой всех версий событий, Вы в основном представили бы компонент, который преобразовывает Ваши события из до более новых версий, и затем примените их на домен. Помните, что события являются вещами, которые на самом деле произошли в Вашем домене так в большинстве случаев, информация в событиях устаревших ценна.
Я все еще не нашел примера этого.
Какая-либо справка?
Есть два основных способа обработки преобразований событий. Оба происходят во время десериализации события:
Вы можете добавлять новые классы с номерами версий (SomethingHappened, SomethingHappened2, SomethingHappened3). Десериализатор создаст экземпляр и заполнит класс, передаст его конвертеру, чтобы получить то же событие в более поздней версии, здесь SomethingHappened3. Одна из проблем заключается в том, что вам придется также обновить обработчики событий, чтобы использовать последняя версия события. Чтобы смягчить это, вы можете использовать соглашение, согласно которому SomethingHappened всегда является последней версией. При переходе к v2 переименуйте SomethingHappened как SomethingHappened1 и создайте SomethingHappened, который будет v2.Для этого вам необходимо иметь контроль над классами, созданными из сериализованного события, поскольку имя сериализованного класса не будет содержать номер версии, вы должны сохранить его в стороне.
Вместо того, чтобы сохранять каждую версию классов в вашем коде, конвертер получит документ (дерево, например, документ Xml или объект JSon) и изменит его, чтобы предоставить информацию, необходимую для построения последней версии.
Все это зависит от вашего контроля над конвейером десериализации.