基于组件的体系结构的粒度

Question

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

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

在基于组件的纯体系结构中，每个类都会受到震动吗？如果不是组件的粒度应该是多少？是否可以使每个组件可重用？

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

Answer 1

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

恕我直言，区分组件和模块非常重要。 组件是一种编程工具：具有行为并可能为其他组件提供服务的东西。在实现方面，您使用OSGi的组件模型之一（例如Declarative Services）对组件进行编程。见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