一点背景知识——我们正在设计一个使用客户端/服务器架构的应用程序，包括：
- 加载服务器端模块的服务器，可能由其他团队开发。
- 加载相应客户端模块的客户端（也可能由其他团队开发；每个客户端模块对应一个服务器模块）。
- 客户端与服务器端通信以进行一般协调，以及模块特定任务。（此时，我认为这意味着客户端与服务器对话，客户端模块与服务器模块对话。）
- 环境是.NET 3.5，客户端是WPF。
部署方案引入了独立升级服务器、任何服务器端模块、客户端和任何客户端模块的潜力。但是，需要能够使用不匹配的版本“工作”。因此，我担心版本控制问题。
到目前为止我的想法：
- 服务器的 Windows 服务。
- 使用 System.AddIn 为服务器加载和与服务器模块通信将在服务器和服务器模块之间的版本兼容性方面为我们提供最大的灵活性。
- 服务器和各个服务器模块提供 WCF 服务与客户端进行通信；服务器和服务器模块之间或两个服务器模块之间的通信使用 AddIn 合同。（这样做的一个优点是模块可以在服务器内部和外部公开不同的接口。）
- 同样，客户端使用 System.AddIn 来查找、加载客户端模块并与之通信。
- 客户端与客户端模块的通信是通过 AddIn 接口进行的；从客户端和从客户端模块到服务器端的通信是通过 WCF 进行的。
- 为了获得最大的弹性，每个模块将在单独的应用程序域中运行。
- 一般来说，系统的性能要求适中，因此编组和跨越进程边界预计不会成为性能问题。（性能要求基本上总结为：不要妨碍此处未描述的系统其他部分。）
我的问题是关于使用两种不同的通信和版本控制模型的想法，这将给我们的开发人员增加负担。System.AddIn 看起来很强大，但也有点笨拙。（我也不确定微软在未来对它的承诺。）另一方面，我对 WCF 的版本控制能力并不感到兴奋。我有一种感觉，可以在 WCF 中实现 System.AddIn 视图/适配器/合同系统，但是对于这两种技术来说都是相当新的，我不知道从哪里开始。
所以...我在正确的轨道上吗？我这样做很难吗？在这条路上我需要注意什么问题吗？
谢谢。