Discussion :

[p@radox]

salut à toute la communauté

je suis en train de bosser sur un projet de refonte, ou grosso modo nous avons contruit un front-end et un back-end. Front en angularjs/grunt/etc et back restfull en jersey/spring/hibernate
pour l'instant nous avons 2 projets séparé ( donc 2 war ) , on se pose la question de découper davantage la partie backend, en sous module. notemment isoler la partie acces aux données de la partie rest (controller)
pour l'instant voici l'arbo des packages à la racine de notre main/java/maboite/ :
- config
- controller
- dao
- dto
- filter
- model
- repository ( JpaRepository )
- security
- service
- utils



j'espere que les packages vous parlent, donc voici ma question, quels avantages réels et objectifs d'avoir à découper ce projet en sous module ?

Merci de vos conseils.

A vous lire, et bon week end quelques heures en avances !

[herve91]

Bonjour,

J'ai réalisé le même travail de découpage sur une application de même type, l'idée étant d'avoir plusieurs applications web indépendantes, appelées micro services, dans le but d'avoir moins de test à faire (seuls les modules impactés sont à tester).
Au niveau architecture, les classes communes sont identifiées et reparties en modules dits "commun" :
- couche modele : model, dto : c'est dans ce module que doit résider l'ensemble des classes de mapping objet/relationnel (entités jpa)
- couche d'acces aux données : dao, jpaRepository
- couche services : service, utils
Ensuite, pour chaque module applicatif, on trouve les packages suivants :
- couche modèle : dto specifiques
- couche acces aux donnees : dao, jpaRepository specifiques
- couche services : service, utils spécifiques
- couche web : config, controller, filter, security spécifiques
Le lien entre chacun des modules applicatifs et les modules communs est réalisé grace a la mise en place d'un contexte partagé spring (shared context).
C'est très intéressant au niveau maintenance, les modifications étant localisées aux seuls modules impactees. Chaque module en lui même embarque les seules classes qui le composent, ce qui permet de produire des War de très petite taille (les dépendances ne sont pas embarques dans le war mais fournis par le serveur d applications : maven provided versus compiled).
Enfin chaque module ne doit concerner qu'un domaine applicatif, et exposer un sous ensemble des url.

[p@radox]

merci herve91 pour ta reponse tres interessant, c'est en effet la premiere partie de ton message qui répond à ma question. L'idée derriere est aussi de créer des micro-services mais ne sommes pas encore là. cela je note ton idée de module commun et son découpage.

de mon coté j'avais effectivement commencé un découpage de la sorte :

- data (dao, jpaRepository)
- model ( entités jpa , constantes, bean/dto )
- business ( services )
- web ( controller etc)


Mais je note ton idée de regrouper des classes communes dans un module ( découpés par catégories ) et ensuite de de tirer un dépendances vers ce module commun à partir de l'application web