Discussion :

[onclezeb]

Soumission d’un petit problème d’archi : un projet Maven multi modules :
- Parent (pom.xml, gestion des versions)
- Core (Spring, Hibernate, etc…)
- IHM (Spring MVC, Thymeleaf, Bootstrap, etc…)
- Rules (Implémentation du pattern Specification)
- Batch (Spring Batch)
Jusque là, rien de neuf
Le souci se situe au niveau des dépendances entre ces différents modules :
- IHM doit voir Core : IHM a besoin des méthodes de services du Core et de ses DTO (paramètres d’entrées/sorties des services)
- Core doit voir Rules : Core doit pouvoir appliquer des règles métiers sur tout ou partie de ses DTO/Entités
- Rules doit voir Core : il est possible que pour exécuter certaines règles, le moteur de règle doive avoir accès à la base de données (ça commence à piquer… )
- IHM doit voir Rules : les règles étant centralisées dans le moteur de règles et qu’on ne veut pas les dupliquer, certaines règles IHM métier seront présentent dans le moteur de règle
- Batch doit voir Core : les batchs vont faire appel à la base de données
- Core doit voir Batch : pour l’administration des batchs (là, çà repique… )
Donc comme on peut le voir, on se retrouve avec des références circulaires, Maven n’aime pas
Pour la partie Batch, l’utilisation de ItemReaderAdapter/ItemWriterAdapter serait une solution mais cela voudrait dire de copier, à la compile via Maven, tout le contexte Spring du Core (Config Spring, persitence.xml, les classes, etc…) Un peu lourd… mais faisable...
On pourrait penser la même chose pour Core/Rules, mais cela risque de ne pas fonctionner car on change de contexte (genre IllegalArgumentException au runtime)
Je lance la discussion. Si vous avez des idées

[Cafeinoman]

Pourquoi ne pas "simplement" sortir la partie accès bdd de core? Un module supplémentaire vu par Rules, Batch et Core. Ca supprime toute référence circulaire, même si j'admet que ca peut faire un gros refactoring si le projet est avancé...

[onclezeb]

Merci de ta réponse Cafeinoman

J'y ai déjà pensé. Le projet suit les principes MDA : les parties Core de IHM sont générées. Notamment, les services et les DAOs sont dans le même artefact : Core.
Pour l'instant, il me parait compliqué de tordre l'outil pour splitter ces 2 parties. Mais c'est une de mes pistes

D'autres pistes ?

[onclezeb]

Pour infos, pour le Core, l'outil produit 2 artefactes :

• un (client) avec les interfaces de services, les DTOs, les entités, les exceptions, les énumérations
• un autre avec les implementations de services et la partie DAO

[sekaijin]

je ne suis pas sur d'avoir tous saisi

pour moi "core" n'a souvent pas beaucoup de sens.

je serais aussi d'avis que la persistance (DAO) ne doit par faire partie de "core"
je verrais bien un triptyque services rules persistance.
persistance ne dépend de rien
rules et services utilisent persistance.
services utilise rules.

ensuite batch et IHM utilisent services

A+JYT

[onclezeb]

Ok, je vois. Si je résume :

IHM----\+++++++++++/->Rules--\
+++++++\+++++++++/+++++++++\
++++++++->Services --------------> Persistence
+++++++/
Batch---/

Je suis en train de voir pour un split du core en services+dao... Souffrance en vue...

Mais le lien direct entre Services et Persistence court-circuite Rules. Quelle est sa plus-value ? Les perfs? la facilité? On pourrait effectivement avoir des services n'ayant pas recourt à des règles métiers, on devrait alors avoir la possibilité d'accéder à la base directement... Je suppose.

Dans le cas où le refactoring serait compliqué, une sorte d'IOC via Maven serait-il envisageable ? Je veux dire qu'injecter le Core (services + DAOs) dans Rules (donc à la construction du projet, dans un répertoire source generated par exemple), est-ce que cela ne règlerait pas le problème ? Alors j'entends la critique du "copier/coller" ! Mais finalement, la source est unique, et l'artefact est généré par la même unité de travail à la compilation !

Cdt,