Généralités Conception modulaire pour une application Web

Question

De tous ceux qui ont conçu une application d'entreprise modulaire, j'aimerais savoir comment vous percevez la modularisation et quels sont exactement vos paramètres?

1. La modularisation basée sur les couches (comme un contrôleur/module web, un module de service, un module de domaine) est-elle une meilleure approche?
2. Ou la modularisation à base de fonctionnalités mieux? Et pourquoi?
3. Dans le cas d'une modularisation basée sur des fonctions, comment empêcher/résoudre les dépendances circulaires entre différents modules de fonctions dépendants du service de l'autre?

Il s'agit plus d'une question de conception basée sur l'expérience et implique donc un mélange d'opinion basée sur cette expérience.

Answer 1

Vous devriez utiliser la fonctionnalité basée sur la modularisation basée sur les couches apporte très peu d'avantages. Bien sûr, cela ne signifie pas que vous devez complètement ignorer les couches (logicielles). Si vous considérez les modules comme des composants déployables (par exemple, des artefacts Maven, des JARs dans EAR), l'une des principales raisons pour cela est de diviser l'application en plusieurs parties pouvant être activées et désactivées pour certains clients/déploiements. . Dans ce cas, la modularisation basée sur les fonctionnalités est la voie à suivre.

Même si vous êtes sûr que vous n'aurez pas besoin de ce type de déploiement, je vous suggère quand même d'aller vers la modularisation basée sur les fonctionnalités. Les interfaces entre les modules d'entités ont tendance à être beaucoup plus petites (et donc plus faciles à gérer) qu'entre les couches. En outre, les personnes qui travaillent sur les deux couches adjacentes sont généralement les mêmes, ce qui fait que la séparation des modules est difficile et souvent entrave la mise en place sans aucun bénéfice. À moins de penser aux «grandes couches» (interface utilisateur, logique métier, base de données), auquel cas c'est faisable. Dans ce cas, je suggérerais la «modularisation matricielle» (c'est-à-dire la modularisation des fonctions et des couches), mais avec des équipes basées sur les caractéristiques/responsabilités individuelles avec quelques rôles spécialisés pour les parties difficiles. Par exemple, un concepteur pour l'interface graphique et plusieurs programmeurs travaillent chacun sur des modules d'entités distincts, qui incluent une interface graphique. Comme pour la question 3: essayez de décomposer encore plus ces deux modules. Ils sont généralement trop grossiers. Si elles s'avèrent ne pas être après une réflexion/discussion, vous devez les séparer artificiellement juste pour éviter la circularité. Si cela ne va pas, esp. Si vous finissez avec des modules vraiment minuscules, fusionnez-les en un seul module. Juste ne pas essayer de fusionner comme première étape.