基于组件的架构的粒度

Question

虽然我是一名 Java 开发人员，而且这个问题涉及 OSGi 和 Java 的模块化，但这个问题确实适用于任何面向对象的 3GL。

我开始掌握真正“模块化”开发的概念，并开始真正喜欢上 OSGi。我第一次开始考虑在非常精细、可重用、专门的部署中部署 jar。然而，这种新的思维方式引发了一些问题。

在纯粹的基于组件的体系结构中，每个类都会受到干扰吗？如果不是，组件应该有多精细？是否有可能让每个组件都可重用？

在确定模块化组件的粒度时，可以使用哪些“经验法则”？提前致谢！

Answer 1

我主要从 OSGi 的角度来回答这个问题。

恕我直言，区分组件和模块很重要。 组件 是一种编程人工制品：具有行为并可以为其他组件提供服务的东西。在实现方面，您使用 OSGi 的一种组件模型（例如声明式服务）对组件进行编程。见http://wiki.osgi.org/wiki/Component_Models_Overview

模块 是一个部署工件：它是将组件和/或 API 打包成一个工件，可以在各种运行时复制和安装。因此，您可以隐式地将多个组件打包在一个模块中，或者为每个组件创建一个模块。

事实上，模块内容很容易重构，因此您不必预先担心粒度：随着您对 OSGi 的了解越来越多，您会找到适合自己需要的级别。但请记住以下一般建议：

1. 打包在同一模块中的组件一起（重新）部署。如果其中一个组件的发布频率高于其他组件，那么您可能会通过重复发布未更改的组件来创建不必要的工作（例如，下游消费者的测试），只是因为它们恰好与更改的组件位于同一模块中.
2. 无法部署半个模块。因此，一个模块中的所有组件都应该是密切相关的，所以你不会让用户希望“如果我可以只部署这个模块中的一些组件”...
3. API 更改非常缓慢且谨慎，而组件更改频繁。由于这个和其他原因，API 最好部署在它们自己的 API 包中。见http://wiki.osgi.org/wiki/Separate_API_from_Implementation
4. 为了确保可以在不破坏用户的情况下重构模块内容，请始终使用Import-Package 而不是Require-Bundle 来表达您的依赖关系。见http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle