解耦

今天小董给大家做了一个关于DMTP的精彩演讲，DMTP种种优秀的特性令我们这些听众叹为观止。

为何DMTP具有如此魔法呢？

也许要从spring integration说起，除了实现了企业集成模式外，它还是作为一个微服务设计的。也就是说，DMTP自然也具有独立开发维护和部署，以及易于扩展的敏捷特性。
代码解耦以后各个模块也就变得相对简单，易于重用，易于分析impact，易于单元测试和保证质量。当某功能模块的发布也解耦的时候，这个组件就可以独自更新测试发布，并且升级扩展，这就是微服务。

从信息被减少的角度来看，抽象是解耦天然的解决方案。解耦是横向的隔离，这种隔离可以基于抽象这种纵向的隔离机制之上。除了各种基于接口的面向对象的设计模式以外，代理显然也是解耦的方案之一。

想一想社会的高度精细化分工，不正是解耦的绝佳例子吗，生产汽车的厂商要同轮胎厂商合作，才能最终完成产品。其中轮胎厂商专注于轮胎的生产，它的生成运营，特色化服务，甚至技术进步，都能独立完成。反过来汽车厂商也是一样，而且一旦轮胎是符合标准的，汽车厂商可以随时更换轮胎供应商，这叫portability。
还有各种第三方运营，是使用代理解耦的一种表现

自然而然的，一些问题产生了：

• 假如将功能P分拆为A，B，C三个部分，怎么能确定这样分是最优的，拆分的原则是什么，A，B，C的边界在哪里？

• 是不是拆分的粒度越小越好，怎样决定粒度的大小？

• 对于做interface 这件事，ISDC经验丰富，怎样考虑到解耦enterprise integration，障碍在哪里？

• 若自己考虑拆分integration的模块，也会得到endpoint, channel, filter…这些抽象组件么，差别是如何造成的？

• 学习spring integration是否有助于理解学习其它包含抽象概念的framework？

思考是一种乐趣，欢迎交流：-)