根据复用颗粒大小，复用包含如下
- 类复用，采用继承或者委托
- 第三方包复用，常见的WEB-INF/lib目录下一堆jar文件既是这种场景，通常适用于工具类
- 代码复用，CC（ClearCase）等配置管理支持，直接把其他项目的模块的代码引用到另一个项目中
- 服务服用，把某种服务使用特定的消息接口开放出来，进而复用
基本上，第三种复用已经很少了，支持这种复用的配置管理工具更少，我只看到过CC还支持这个。确实这种缺陷太明显了。其他的几种复用倒是常见，然而对一个企业而言，这还不够。
企业长期的开发过程会积累大量的可用业务模块，例如说CMS（内容管理）、安全管理（用户、角色等），如果新开发的系统从这些可用的业务模块的基础上拼装而不是从类的基础上拼装，则能够大大提升开发效率。
flying正是这样一个框架，它通过组装一个个细小的业务模块，从而形成功能完备的大型业务系统，包括如下优势：
- 所有模块的对外接口具备完整的规范，参考本地服务调用和远程服务调用文章
- 开发过程只需关注正在开发的模块
- 测试范围大大缩小
- 只需要部署改动的模块
- 企业可以完成模块积累
理想的情况下，企业建立自己的模块库。一个新应用立项后，拆分，然后从模块库中找出可以复用的模块，如无需修改，则直接使用，如需要修改，创建模块的分支修改并使用。如果在新作应用过程中出现有价值可以复用的模块，进入模块库统一管理。
框架源码：https://github.com/hifong/flying
博客空间：http://www.cnblogs.com/hifong/
Demo应用：https://github.com/hifong/pas
技术QQ群：455852142