我们的Message和SagaData类都包含在解决方案中央模型项目中定义的属性。现在，我们正在重构我们的解决方案，以便我们有一个特定的项目，在该项目中将定义NServiceBus类的属性。我们这样做是希望将Nsb层与应用程序的其余部分分离，并避免在解决方案的Model项目更改时避免不必要地污染我们的Nsb类。
特定于Nsb的Model（Nsb.Model）项目将紧密反映中央Model项目，而AutoMapper将负责从Nsb.Model Model映射我们的对象。
我认为我们不必太担心重构我们的Message类，因为它应该足够安全，可以在没有运行中的消息时简单地部署此更改（我们将有很多机会这样做）
我更担心我们的Saga和SagaData类。总是会有一些Saga在运行（大多数情况下是在等待超时的休眠状态），当我们对SagaData类进行更改时，我担心已经运行Saga会出现问题。对SagaData类的更改基本上是引用新的程序集（Nsb.Model），该程序集具有与旧程序集（模型）相同的类。其中一个类已在新程序集中重命名，但它们与旧类完全相同。
我们正在使用NHibernate作为持久性。我已经在测试环境中尝试了单个Saga，并在Saga等待超时时部署了更改，看来更新的程序集或其中一个属性类的名称更改基本上都没有问题。但是，我不愿意将其部署到生产环境中，而没有完全了解它可能产生的影响以及一旦部署将使我们的应用程序保持健康。
非常感谢任何见识。谢谢
NServiceBus使用NHibernate创建表示SagaData类的架构。您可以依赖NHibernate尝试修改当前架构，也可以write migration scripts yourself。
例如，添加属性将导致由NHibernate创建的附加列。对于已存在的所有传奇数据，该列将没有任何值。删除属性将删除该列，并且数据将丢失。
修改集合中的复杂对象会带来困难。知道这是否适用于您的项目的最佳方法是在开发过程中和测试环境中实际执行升级和验证。
我怀疑您已经运行了一段时间，否则SQL Persister（不使用OR / M）使用JSON序列化对象将数据存储在单个列中，并且它依赖于序列化程序的灵活性来进行迁移从版本到版本。与NHibernate相比，我们的客户获得了更好的结果。
但是正如我所说。一种选择是查看之前和之后的状态，然后自己创建迁移脚本。对于复杂的更改，这可能是更好的选择。