java - 基于组件的架构的粒度

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