对于新架构的系统他有什么优点呢？

 首先，也是最重要的就是解决系统的性能问题。以往数据库实例只有一个，没法扩展出多个实例，以便在性能受限的情况下依靠增加数据库实例来达到负载均衡。也许有人会说可以使用读写分离方案，但是因为ERP系统的特点，这个方案很多时候不现实。比如说操作库存的时候，你不能从读库里读库存，然后在写库里写入库存。因为主从复制会有时效性，写入的库存并不能马上写入从库。这样的场景在ERP中也有多处。何况写库不能扩展，只能有一个。而新设计方案是写库是分离的，每个子系统有自己的数据库。

 在这一次交流过程中发现自己已不想再去争论插件化与平常开发的一些优劣了，或许是对现在的“系统架构师”不再抱有什么可以沟通的期望，也不想再与他争论些什么了吧，这一次现在的“系统架构师”还是觉得插件化没有必要，当实现有变更的时候把变更的实现类Copy - Paste - 编译一下发布就好了。想起以往讨论的种种实在觉得悲催，一个要跟他去解释在系统构建中实体优于DataSet、DataTable，同类型不同实例的对象的GetHashCode()方法返回的值是不一致、服务端到客户端经过WCF之后实例是不一致的（省略N件事情）“系统架构师”实在是没有在沟通下去的必要。

 新的架构，只允许我们通过对方的服务接口来获取数据，不能直接关联对方服务的私有数据库。至少从架构上，服务化角度来说不能直接访问对方服务的数据库。这种情况下，假设web模块子系统调用仓库子系统来获取数据，则我们需要在仓库模块中创建一个service方法来装配这些数据。然后返回给web子系统。如下图所示，仓库管理方法首先获取本地库存表的物料编码、和仓库表的仓库名称字段信息，并且分页完后最终准备返回20条数据到Web模块前，将这20条数据中的物料ID作为参数请求商品模块子系统，商品子系统返回这20个物料ID相关的商品信息给到仓库管理模块，然后仓库管理模块重新组装上列表所需的物料名称和品类两个字段数据，实现最终要返回给Web子系统的数据。