bundle的划分建议

划分的原则：
采用OSGi技术实现应用系统时，最终展现在我们面前的将是一个个的Bundle 组件,那么一个应用系统应被划分为几个bundle合适呢？这就涉及到了bundle 划分的实现粒度问题。

我比较倾向于按垂直划分＋水平划分的方式，同时兼顾可重用原则。

根据层次进行划分（垂直）：
∙Services Bundle：在OSGi中，服务是通过Java的接口来定义的，可以把定义服务的Java接口组成一个Services Bundle，并由这个Bundle
向其它Bundle提供接口。

∙服务提供者Bundle：实现Services Bundle提供的接口，并向OSGi框架注册服务。

∙服务使用者Bundle：引用Services Bundle提供的接口，并向OSGi框架请求相应的服务。

根据MVC进行划分（水平）：
∙模型
∙视图
∙控制器
根据可重用原则进行划分：
∙一些公共操作应提取成单独的bundle，比如工具集。

根据业务功能进行划分：
∙比如销售管理模块、库存管理模块，复杂大型项目我建议这么做，小型项目只需按垂直划分＋水平划分的方式即可。

举例：
将一个应用部署到OSGi中更好的结构是将这些应用打包成一系列的bundles，它们通过OSGi service registry 相互作用。

独立的子系统应该被打包成一个独立的bundle或划分成多个bundles（垂直划分）或是通过不通的层划分成多个bundles（水平划分）。

例如，一个简单的web application可能会被划分成4个模块（4个bundle）：页面显示层bundle，服务层bundle，数据层
bundle和域模型 bundl，那么服务层bundle还可以划分为接口和实现2个bundle。

划分的细度是不是越细越好？
我个人认为不好，不能一味的强调细，细度越细，需要考虑的越多，例如注意模块的启动顺序无关性及对其所依赖服务的监听等，这些都会大大增加系统实现和调试的复杂性，为Bundle的部署与管理都会提出更高的要求。