Granularité des architectures à base de composants

Question

Bien que je sois un développeur Java et que cette question concerne l'OSGi et la modularité selon Java, la question s'applique vraiment à tout objet 3GL orienté objet. Je commence à saisir les concepts du développement véritablement «modulaire» et commence à prendre un réel goût pour OSGi. Pour la première fois, je commence à penser à déployer des pots dans des déploiements spécialisés, très granulaires, réutilisables. Cependant, ce nouveau mode de pensée a soulevé quelques questions.

Dans les architectures basées sur des composants purs, est-ce que toutes les classes sont en conflit? Si non, à quel point les composants doivent-ils être granulaires? Est-il possible de rendre chaque composant réutilisable?

Quelles sont les «règles générales» à utiliser pour déterminer la granularité d'un composant modulaire? Merci d'avance! Je vais répondre à cette question principalement d'un point de vue OSGi:

Answer 1

À mon humble avis, il est important de faire la distinction entre composants et modules. Un composant est un artefact de programmation: quelque chose qui a un comportement et peut offrir des services à d'autres composants. En termes de mise en œuvre, vous programmez un composant en utilisant l'un des modèles de composants d'OSGi tels que les services déclaratifs. Voir http://wiki.osgi.org/wiki/Component_Models_Overview

Un module est un artefact de déploiement: il est l'emballage des composants et/ou API dans un artefact qui peut être copié autour et installé dans différents environnements d'exécution. Par conséquent, implicitement, vous pouvez empaqueter plusieurs composants dans un module, OU créer un module par composant. Le fait est que le contenu du module est assez facile à refactoriser, il ne faut donc pas trop se préoccuper de la granularité: plus vous avez d'expérience avec OSGi, plus vous trouverez le bon niveau pour vos besoins. Cependant, gardez à l'esprit le conseil général suivant:

1. Les composants emballés ensemble dans le même module sont (re) déployés ensemble. Si l'un de ces composants est publié plus fréquemment que les autres, vous pouvez créer plus de travail que nécessaire (par exemple, tester par les utilisateurs en aval) en libérant plusieurs fois des composants inchangés, simplement parce qu'ils se trouvent dans le même module que le composant changeant .
2. Impossible de déployer un demi-module. Par conséquent, tous les composants d'un module doivent être étroitement liés, de sorte que les utilisateurs ne souhaitent pas "si seulement je pouvais déployer certains des composants de ce module" "...
3. Les API changent très lentement et avec précaution, tandis que les composants changent fréquemment. Pour cette raison et d'autres, les API sont mieux déployées dans leurs propres ensembles d'API. Voir http://wiki.osgi.org/wiki/Separate_API_from_Implementation
4. Afin de vous assurer que le contenu du module peut être refactorisé sans casser les utilisateurs, exprimez toujours vos dépendances en termes de Import-Package au lieu de Require-Bundle. Voir http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle