IOC思想在系统设计级别的应用

之前有个业务系统，主要完成商品报名到商品发布的流程，在整个流程处理过程中，会跟多个其他系统交互，于是随着这个处理流程的复杂化，编译时需要引入的外部系统客户端越来越多，各种间接依赖冲突也越来越多。每次引入其他业务系统的工作量都是相似的，甚至近似重复的，并且jar之间的冲突还是很难避免的，这样造成了系统演变充满风险，随着引入外部系统的增多，冲突的可能性也越来越多，风险也越来越大，开发人员越来越辛苦，但是系统却越来越不易维护。

面对这种情况，我们首先想着应该对系统做减法，看看能不能简化系统，毕竟足够简化之后才容易维护。首先分析下是什么因素（往往是系统中的变化点，对变化的处理决定着系统的稳定性）导致了系统不断复杂化，是因为系统流程的参与者越来越多，而且参与者的交互方式都很个性化。接下来分析下在业务流程中，各个阶段，和其他系统的交互形式是什么样子的，因为各个业务系统提供的api都是个性化的，所以不太容易看到共同点。然后尝试着在业务层面分析每次和外部系统的交互是做什么操作，这样或许能找到各个操作的共同点，不出意料，交互的目的无非是向外部系统下发一个任务，然后api的返回结果也是可以枚举出来的，perfect！这样系统间交互方式本身就可以进行统一抽象了，在Java中就是interface了。

如果我们定义了这样的一个接口IOutService，这样商品报名到商品发布的流程中，我们的业务系统就直接依赖（编译时依赖）IOutService，而不直接依赖外部系统的api。这个时候IOutService即是我们系统定义的系统交互规范，即规范是由我们系统来定义，即外部系统如果想参与到这个流程的交互过程中，必须遵循该交互规范(实现IOutService接口)。这样我们在系统合作过程中，我们系统成了“甲方”，变被动为主动，由之前的依赖外部系统变成现在的外部系统依赖我们的规范接口，即依赖反转IOC。

这样带来的好处是各个业务系统只需要实现IOutService接口，对外发布成为不同的版本以区分不同的服务，而我们的系统只需要配置不同的版本即可实现对不同服务的调用，切换非常容易，这样可以很容易实现业务流程的配置化，我们系统在IOC基础上构建了基于工作流的流程平台，达到了业务流程定义的随时改变以适应多变的业务逻辑，这样以后有空再分析，但是所有这一套都是基于统一接口的抽象，依赖于这种抽象构建的上层建筑才是稳定的、可以配置化的。

IOC本来就是一个简单的思想，但是系统级别的简单实用却能发挥极大的作用，让系统架构间接很多。关于IOC更深刻的理解，可以参看http://coolshell.cn/articles/9949.html。