Core, IHM, Rules, Batch : archi globale sur un multimodule Maven

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 :mrgreen:
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… :weird:)
- 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… :aie:)
Donc comme on peut le voir, on se retrouve avec des références circulaires, Maven n’aime pas :calim2:
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 :mrgreen:

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é...

Merci de ta réponse Cafeinoman :king:

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 ?

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

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

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... :aie:

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,

Bon, j'ai regardé, à priori, la modélisation semble assez souple pour un split sans trop de dégâts pour le refactoring...
2 modules Maven (services et persistence), services voyant persistence.:ccool:

J'ai toujours mon interrogation sur ce lien direct sans passer par Rules (mais petite interrogation)...:lol:

Au fur et à mesure que j'avance dans l'archi, me vient une autre interrogation : Les devs IHM devraient pouvoir effectuer certaines validations métiers sans pour autant sortir de ce module. Ces règles métiers devraient logiquement se situer dans le module Rules afin d'éviter la duplication de code (ces validations devant se faire également coté services). Un lien devrait donc exister entre IHM et Rules !! On pourrait donc se retrouver avec des problèmes de sécurité car on a là un lien direct à la base données sans passer par Services (IHM-Rules-Persistence)...:moinsser:

Ce que je verrais, c'est donc une API Rules-client dans le module Rules (classifier au sens Maven) qui n'aurait pas d'accès base de données, ou tout au plus un accès très contrôlé.:traine:

Les batchs pourront être soit pilotés par fichiers de config (ou java config) soit par IHM. C'est pour çà que je prévois un lien entre IHM et Batch:?

IHM----\--------------->[(Rules-Client)-->/--Rules]--\
+|+++++\++++++++++++++++++++++++/+++++++++\
+|++++++>-------------------->Services ------------> Persistence
+v+++++/
Batch---/

Quand penser vous ?

Quelque chose comme çà :
Pièce jointe 213469

ça semble plutôt pas mal