模块划分方式回顾

模块的划分，一直是争议比较大的地方，各种方案相去甚远，
模块定义，范围，大小，分包，装配各不相同。
根据不同的产品，项目，可能都会有不同的设计。
如果一个公司自用的快速开发平台，它的模块应该如何设计？
简单确立一下设计目标：
1. 低耦合高内聚
2. 模块复用度高
3. 模块可扩展性强
4. 模块自描述，自包含
5. 模块自发现，自装配
6. 模块以业务为中心
7. 模块易于开发测试
8. 模块易于集成部署
.....
初步设想需要解决：
1. 模块的粒度多大
2. 是否区分功能模块与服务模块
3. 模块如何检测和加载
4. 如何描述模块间的依赖关系,并保证依赖关系稳定
5. 模块如何区隔上下文或名称空间
6. 模块如何统一处理全局风格整体置换
7. 模块间如何以对等的方式互相"侵入"
8. 模块如何统一暴露服务API
9. 模块如何识别SPI策略实现
10.模块扩展点如何设计
11.模块如何注册与发布事件
12.模块如何处理截面，拦截器
13.模块元数据如何定义，方便开发，也方便检测
14.模块如何控制版本
15.模块如何简化部署和分发
......
在刚做完的项目中，系统按主用户群使用范围，划分为运单管理，结算管理，巴枪管理，基础数据管理等子系统，
再按业务功能划分为几十个功能模块，按理论，每个功能模块都能部署到任意子系统中，
并且每个模块就是一个jar包，直接扔到lib目录下，即可使用，
框架自动发现模块，自动装配，自动释放访问资源，自动加载配置，
因为是以项目为中心搭建的框架，所以大量采用了命名约定方式，来处理装配过程，尽量减少配置，
但在开发过程中，因为开发人员较多，培训不够，各开发小组协调差，时间仓促等原因，
出现了命名冲突，循环依赖，开发环境搭建难，集成测试不过，等诸多问题，
最后框架为了应付各种情况，做了很多通容的处理，整体都有些变形，
这是设计之初写的blog文章：
http://javatar.iteye.com/blog/182149
当时和leadyu讨论，也觉得有些风险，但还是用上了。
现在想想，虽然不太完美，但在近半年的优化调整后，以及开发人员的磨合，也算比较通畅，
对下一步开发还是很有帮助的，也希望在此基础上作进一步思考。