Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

#1 12-06-2015 14:01:38

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Migration et architecture ZF2

Bonjour à tous !

Je reviens vers vous, ô grands spécialistes de ZF2, pour discuter de la future architecture de l'application.
Dans ma boite, les précédents devs ont développé une sorte de CRM sous ZF1 qui se présente comme ceci :

   Application                             ---------------------------------> Regroupe toutes les classes "génériques"
        \__ configs
        \__ controllers
        \__ forms
        \__ layout
        \__ models
        \__ clients                         ---------------------------------> Dossier pour les clients
                 \__ client1                ---------------------------------> Dossier pour un client où certaines méthodes sont réécrites / complétées en fonction des spécificités demandées par le client
                         \__ configs
                         \__ controller
                         \__ models
                         \__ views
                 \__ client2
                 \__ ...
        \__ plugins
        \__ views
   Library                                   ---------------------------------> Certaines librairies développés par nos soins sont regroupées ici


Dans le cadre de la migration de notre application sous ZF2, il faut revoir l'architecture mais connaissant très peu ZF2, j'ai du mal à arriver à conceptualiser la future architecture.

1°) D'après vous, faut-il créer un module "générique" qui regrouperait toutes les classes/méthodes utiles au fonctionnement de l'application puis un module par client qui contiendrait ses propres méthodes/classes ?

2°) Doit-on partir plutôt sur la création de différents modules spécifiques (Auth, email...) ? Dans ce cas, comment gérer "l'attribution" de certaines spécificités propres à un client ?

3°) Edit : après réflexion, est-ce envisageable de faire ce type d'architecture ? Un dossier dans vendor avec les classes/méthodes générales à l'application, un dossier dans vendor avec les librairies que l'on a développé et un dossier par client dans le dossier module ? Qu'en est-il de la configuration de l'application dans ce cas là ?

4°) Autre architecture envisageable ?

5°) Si je ne me trompe pas, les classes qui se trouvent dans le dossier library devraient migrées vers le dossier app/vendor ?

Je tiens à préciser que je suis tombé sur ce topic et que je l'ai lu de fond en comble avant de poster ce nouveau message.


En tout cas, merci d'avoir pris le temps de me lire et passez une bonne fin d'après-midi !
Romain

Dernière modification par RomainG (12-06-2015 16:24:07)

Hors ligne

 

#2 23-06-2015 11:02:29

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

Salut à tous !

Désolé pour ce double post mais je relance les questions...
Vous n'avez pas d'idées pour m'éclairer ?

Merci d'avance

Hors ligne

 

#3 23-06-2015 13:53:19

JGreco
Administrateur
Date d'inscription: 22-12-2012
Messages: 432

Re: Migration et architecture ZF2

Bonjour,

Tout d'abord je tiens à préciser qu'il n'y as pas d'architecture type a ton soucis. On fait des choix qui ont chacun des avantages et inconvénients.

Ce que je vais te dire résulte d'un constat lors de mes expériences passées.

Distinguer le code générique qui s'applique au plus grand nombre et ensuite inclure des spécificités par client est une bonne approche. Isoler un maximum ces spécificités est primordiale pour éviter d'avoir du code générant de la dette technique sur un projet (surtout si aucun "ménage" n'est fait si ta boite perd le client).
L'approche que tu as indiqué avec un dossier client n'est pas mauvaise en soi, si tout ce qui concerne les spécificités du client sont dedans, cela me semble plutôt propre.

Je reviens sur la notions de module au sens ZF2. Un module est destiné à être réutilisé, si tu le sortait de ton application pour l'inclure dans un autre projet tel quel, cela doit marcher.

Je travaille aussi comme toi sur une application multi-client. Je me sers de la base de donnée comme tampon pour gérer les spécificités finalement commune, le client la possède ou pas, si oui je lui applique ses spécificités. Car une spécificité du genre je possède une numéro de "commande ouverte" le distingue des autres comme une particularité, mais peut potentiellement concerner d'autre clients. Rendre le spécifique, générique est pas simple, mais au final même des grands comptes ont des particularités qui en fait sont commune, juste pas décrite de la même façon.

J'ai donc plusieurs formulaire de configurations, qui centralise tous ce qu'il y a de commun et de spécifique et qui ensuite est traité dans le même code, et passe par la même sorties de traitement. Et dans mon code "null" part, je n'ai fait de condition sur un client. Mais cela ne marche que dans certains cas.

Admettons que tu aies des clients qui se connectent et doivent avoir leur interface personnalisée, la tu es bloqué ta vue est super spécifique à ce que le client demande :
"je veux qu'on décale de 1 pixel ce block là", "ici il faut que ce soit marqué 'toto' et non pas 'titi'" ...etc.
La tu ne peut te soustraire a faire un dossier de vue spécifique. Et ton idée d'avoir un dossier client n'est pas mauvaise pour traiter de cela.


ZF2 et doctrine addict
profil stack overflow : http://stackoverflow.com/users/3333246/ … ab=profile

Hors ligne

 

#4 23-06-2015 15:13:32

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

Merci pour ta réponse JGreco !

JGreco a écrit:

Tout d'abord je tiens à préciser qu'il n'y as pas d'architecture type a ton soucis. On fait des choix qui ont chacun des avantages et inconvénients.

Je tiens à te rassurer, j'en ai parfaitement conscience. Si j'ai posé cette question, c'est pour avoir vos retours d'expérience afin de faire le bon choix par la suite (même si cela risque d'être difficile).

JGreco a écrit:

L'approche que tu as indiqué avec un dossier client n'est pas mauvaise en soi, si tout ce qui concerne les spécificités du client sont dedans, cela me semble plutôt propre.

Justement, tu conseillerais l'approche 1 ou 3 que j'ai décrite lors de mon premier post ?
Je pense que l'approche 3 serait peut être plus "module-friendly" selon ZF2 mais vu mon manque d'expérience dans ce domaine, difficile à moi de le dire.

Après, comme tu le dis, un module est destiné à être réutilisé mais dans notre cas, ce ne sera pas le forcement vrai. D'après ce que j'ai compris, cette histoire de modularité et réutilisation de module est plus destinée au partage avec la communauté, ce qui dans le cas de notre boite sera fort peu probable...

En tout cas, pour une personne qui découvre ZF2, c'est vraiment prise de tête mais c'est aussi un pur régal pour se creuser le cerveau !

Hors ligne

 

#5 23-06-2015 17:50:31

Orkin
Administrateur
Lieu: Paris
Date d'inscription: 09-12-2011
Messages: 1261

Re: Migration et architecture ZF2

Hello, dit donc l'article est ultra vieux, je m'en souvenais même pas :p.

Pour ta première question je dirais comme ce qui est fait plus haut. L'idée c'est d'avoir un module par type de fonctionnalité et si possible le plus indépendant possible. C'est à dire que ton module (dans la mesure du possible) doit avoir le moins de dépendances. On va dire que tu as un module de facturation et que suivant les clients la facturation est différente ton module doit être assez intelligent pour être capable de générer n'importe quelle facture de n'importe quel client sans que tu aies à toucher au code. Si tu dois faire un déploiement à chaque fois c'est galère (par moment il n'y a pas le choix hein). L'idée de JGreco peut être bonne si ta table de configuration n'est pas trop complexe et que tu as un backoffice qui te permet de configurer pleinement la facturation. En allant des infos à récupérer jusqu'au template par exemple.
Si on prend un exemple d'export par exemple tu peux avoir un module générique qui fait toute la logique d'export et des modules qui ont comme dépendance ce premier module d'export mais implémente des spécificités. Par exemple tu veux exporter au format au format CSV tu pourrais avoir un module qui le fait, pareil pour le PDF, ou encore en fonction du type de data que tu veux exporter. Ca dépend de ton besoin.

RomainG a écrit:

2°) Doit-on partir plutôt sur la création de différents modules spécifiques (Auth, email...) ? Dans ce cas, comment gérer "l'attribution" de certaines spécificités propres à un client ?

Oui tu peux le gérer comme dit plus haut via une table de configuration, un fichier de configuration et éventuellement un backoffice

RomainG a écrit:

3°) Edit : après réflexion, est-ce envisageable de faire ce type d'architecture ? Un dossier dans vendor avec les classes/méthodes générales à l'application, un dossier dans vendor avec les librairies que l'on a développé et un dossier par client dans le dossier module ? Qu'en est-il de la configuration de l'application dans ce cas là ?

Je pense que tu vas t'y perdre. Tu peux t'orienter vers une architecture micro-services. Avec l'arrivée du ZF3 et la séparation du ZF2 composant par composant tu peux regarder du côté de Zend-Stratigility (le middleware de zend) et Zend-diactoros qui est l'implémentation de la PSR7 par Zend. Ces outils te permettent de t'orienter vers des architectures micro-service. Plutôt que d'avoir une grosse application ultra complexe avec plein de choses dedans tu peux avoir plusieurs petites applications.
Donc on peut dire que tu as une application squelette qui te sert de base que tu peux aussi enrichir si jamais plusieurs clients te demandent la même chose tu peux peut être le proposer à tes autres clients ? Ca fait évoluer ton produit (quitte à les bloquer et les rendre payantes). L'idée c'est donc de déployer une application par client. C'est beaucoup moins compliqué en cas de modification de code puisque ça n'impact qu'un seul à chaque fois. Pour ça tu dois bien découper tes modules.
Si on reprend l'exemple des exports tu vas avoir ton squelette qui propose par défaut l'export de la base user (du client) au format CSV. Tu vas donc avoir 2 modules un pour gérer l'export et un pour gérer la partie CSV (le découpage c'est au pif c'est à toi de voir wink). Ton client 1 n'a besoin que de ça donc ton point d'entrée de ton application va interroger ce micro-service.
Ton client 2 lui veut l'export au format PDF. C'est emmerdant parce que ton client 1 n'en a pas besoin, tu peux donc faire un nouveau module pour faire ça et déployer un clone de ton premier micro-service + ce module pour ton client 2. De cette façon tu as bien une appli par client (avec un socle commun). Demain ton client 3 veut aussi le PDF, pas de soucis tu peux lui proposer la prestation très rapidement. Si le sur-lendemain ton client 1 veut la même chose c'est très simple aussi (tu fais tout via composer).
Petit à petit tu peux avoir des spécificité différentes avec des configurations différentes qui n'impactent qu'un seul client à la fois et tu es beaucoup plus libre. Si tu fais ça bien avec les évènements tu as aucune dépendances et aucun code à faire pour intégrer une nouvelle fonctionnalité à une appli déjà existante.

J'ai ce cas pour un module de mail. Dans mes projets je lance un évènement pour un envoi de mail. Tous les paramètres dont j'ai besoin pour le traiter sont envoyés dans les paramètres de l'évènement. Si jamais je n'ai pas activé mon module de mail l'évènement par dans le vent et le mail n'est pas envoyé et mon application ne plante pas. Si j'ai le module de mail activé mon listener est donc présent, il capture l'évènement et le traite. De cette façon je peux facilement intégrer le module à une application (à partir du moment où moi dans ma phase de développement je prend le soin de lancer les évènements (au cas où j'en ai besoin plus tard).

Hors ligne

 

#6 24-06-2015 10:16:17

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

Merci pour ta réponse Orkin.

Orkin a écrit:

Pour ta première question je dirais comme ce qui est fait plus haut. L'idée c'est d'avoir un module par type de fonctionnalité et si possible le plus indépendant possible.

Si je comprends bien, en reprenant l'architecture de ZF2, tu conseillerais de faire quelque chose du style :

App
        \__ configs
        \__ data
        \__ modules
                 \__ Auth               ---------------------------->Module générique
                 \__ Facturation      ---------------------------->Module générique
                 \__ ...                   ---------------------------->Autres modules génériques
                 \__ client1             ---------------------------->Module spécifique au client 1
                 \__ client2             ---------------------------->Module spécifique au client 2
        \__ public
                 \__ client1             ---------------------------->Dossier public spécifique au client 1
                 \__ client2             ---------------------------->Dossier public spécifique au client 2
        \__ vendors


Orkin a écrit:

Tu peux t'orienter vers une architecture micro-services. Avec l'arrivée du ZF3 et la séparation du ZF2 composant par composant tu peux regarder du côté de Zend-Stratigility (le middleware de zend) et Zend-diactoros qui est l'implémentation de la PSR7 par Zend. Ces outils te permettent de t'orienter vers des architectures micro-service.

J'ai regardé ça et je trouve que c'est un peu trop complexe pour moi. Je comprends tout à fait le concept (et j'avoue que je l'essaierais bien) mais je ne vois pas trop comment le mettre en place dans mon cas...
Je pense quand même rester dans un schéma classique d'application, avec tout les avantages et inconvénients que cela implique...

Dernière petite question. Si je comprends bien ton système d’événements, chaque module spécifique (client) envoie des événements qui sont captés ou non par les modules génériques. S'ils contiennent un listener, ceux-ci sont "activés" et utilisés par le module spécifique ?

Hors ligne

 

#7 24-06-2015 11:01:08

Orkin
Administrateur
Lieu: Paris
Date d'inscription: 09-12-2011
Messages: 1261

Re: Migration et architecture ZF2

Pour ton architecture oui ça serait un truc comme ça sachant que des modules clients ont des dépendances à ton module générique puisqu'il en modifie le comportement.

En gros l'architecture micro-service tu vas avoir ton application comme tu as maintenant qui va interroger une autre application (en l'occurence un micro-service) qui sera différent en fonction du client. Ensuite ton micro-service retourne la réponse à ton application et celle-ci répond à ton client ! Au final ton application fait "proxy" pour savoir quel micro-service il doit interroger.

Voila c'est ça tu fais l'effort dans ton application de lancer des évènements. Par exemple quand un utilisateur va s'inscrire au début de l'inscription tu peux lancer un évènement pour faire du monitoring (si ton module de monitoring est activé avec son listeneur il pourra traiter l'évènement), à la fin de l'inscription tu peux aussi lancer un évènement d'envoi de mail (si ton module d'envoi de mail est activé avec son listeneur il enverra le mail de bienvenue par exemple) etc ...
Donc dans ton cas tu pourrais avoir des listeneurs un peu plus complexes qui sont capable d'identifier le client qui est à l'origine de l'envoi de l'évènement et le traiter ou non.

Hors ligne

 

#8 24-06-2015 11:15:05

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

OK. Merci pour tes précisions !
C'est vrai que l'architecture micro-service est vraiment alléchante au final, mais je vais rester dans un style d'application plus "classique".

Je reviendrais vers vous pour d'autres questions !

Hors ligne

 

#9 28-07-2015 09:49:45

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

Bonjour à tous et désolé du double post...

Je reviens vers vous car j'ai encore des questions à propos de l'architecture du projet suite à la migration.
En fait, je dois compléter mon avant dernier post dans lequel je présentais la possible architecture du projet.

Ce que j'avais oublié de préciser c'est que pour chaque client, on développe des "webApp" différentes. Globalement, pour chaque client, on a :

Code:

    \_ admin
    \_ front
        \_ boutique
        \_ site vitrine
        \_ espace user

Dans l'immédiat, cela ne semble pas poser de problème...

Mais en fait, ce qu'il faut bien voir c'est que chaque client a accès à la partie admin (générique mais chaque client a des spécificités différentes). Cette partie admin est située sur un nom de domaine particulier.

En ce qui concerne la partie "front", elle possède également une structure commune à chaque client mais là aussi avec des spécificités différentes pour chaque client. De plus, cette partie est situé sur un autre nom de domaine.

Ce que je pensais faire, afin de faciliter le déploiement à chaque nouveau client ajouté, c'est une architecture du style :

Code:

admin
   \_ config
   \_ data
   \_ module
      \_ Auth
      \_ Facturation
      \_ ...
      \_ client_1
      \_ client_2
   \_ public
      \_ client_1
         \_ index.php ---> permet de charger ZF2 et les modules spécifiques pour le client_1
      \_ client_2
         \_ index.php ---> permet de charger ZF2 et les modules spécifiques pour le client_2
   \_ vendor

front
   \_ config
   \_ data
   \_ module
      \_ Auth
      \_ Facturation
      \_ Boutique
      \_ ...
      \_ client_1
      \_ client_2
   \_ public
      \_ client_1
         \_ index.php ---> permet de charger ZF2 et les modules spécifiques pour le client client_1
      \_ client_2
         \_ index.php ---> permet de charger ZF2 et les modules spécifiques pour le client client_2
   \_ vendor

Dans ce cas, on n'aurait qu'à rajouter un module "client" et d'ajouter les paramètres pour celui-ci.

Le problème, c'est que certains modules développés sont communs aux deux "applications" et que certains modules de la partie front doivent pouvoir communiquer avec la partie admin (ex: traitement d'une commande boutique qui se réalise côté admin)...
Dans le cas d'une utilisation multi-domaine, j'ai peur que cette architecture ne fonctionne plus...


D'après vous, est-ce une architecture qui est potentiellement faisable ?
J'avais pensé dupliquer la partie front en faisant une app par client mais on va vite se retrouver avec de nombreuses app front... Peut être pas trop idéal pour maintenir l'application ?

Qu'en pensez-vous ?

J'avoue que je commence à être sacrément perdu au niveau de cette architecture...

Désolé d'insister sur ce sujet en posant des questions qui peuvent paraître triviales mais je n'ai pas envie de partir tête baissée sur une architecture et me rendre compte, après plusieurs semaines de développement, qu'elle n'est pas adaptée dans notre situation...

Merci d'avance,
Romain

Hors ligne

 

#10 28-07-2015 10:23:04

Orkin
Administrateur
Lieu: Paris
Date d'inscription: 09-12-2011
Messages: 1261

Re: Migration et architecture ZF2

Salut, je t'avoue que ça commence à être un peu compliqué à suivre. Tu as je pense plusieurs solutions. La première c'est via des variables d'environnement dans ton index.php suivant la variable ça va charger le fichier de configuration associé et/ou les modules qui vont bien mais ça implique d'avoir un fichier application.config.php un peu gros et vite bordélique.
J'aurais envi de te proposer une autre approche peut être un peu plus longue à mettre en place car un peu plus de boulot. C'est de développer ton application en mode API/micro-services de ce fait tu vas avoir une grosse application (ou un groupe de plusieurs) qui vont être disponibles.
Pour tes clients tu développes des webapp différentes (dans cette configuration tu peux vraiment tout avoir, application mobile, client JS etc ...) là du coup tu es un peu obligé de mettre de côté le bon vieux site web avec des pages générées côtés serveur. Enfin ça fonctionnera avec mais tu devrais faire des appels à ton api directement dedans donc potentiellement des temps de chargement un peu plus long. Avec ça + une bonne gestion de droit tu seras en mesure de service n'importe quelle application à tes clients. C'est ton application web qui va avoir la logique pour récupérer les informations en fonction des spécificités.

Hors ligne

 

#11 28-07-2015 10:30:44

flobrflo
Membre
Lieu: Marseille
Date d'inscription: 26-04-2013
Messages: 376

Re: Migration et architecture ZF2

Hello,

Pour ton appli l'architecture peu correspondre si tu a beaucoup de trafic sur tes différents sites, pour la maintenance si tes modules sont vraiment similaire, il faut juste bien penser à les mettre à jours des deux cotés.
C'est un peu contraignant mais tu pourra alléger tes admins lorsque les fronts seront un peu chargé.

Maintenant si tu n'a pas de contrainte coté perf, tout réunir dans un seul projet te permettra une maintenance plus aisée.
(mise à jour des modules et du cœur) Cela te demandera moins de rigueur ^^

tu pourrais faire un truc du type :
public /
         admin/
                  client1/
                  client2/
         front/
                 client1/
                   ....

avec tes modules communs dans ton application qui gèrent le front et l'admin (comme tu dis, généralement on utilise les même fonction de coeur, juste la mise en forme change ^^)

Mais comme disait JGreco, il n'y a pas d'architecture type, juste pleins de possibilités ^^

Hors ligne

 

#12 28-07-2015 11:09:33

RomainG
Membre
Date d'inscription: 10-06-2015
Messages: 65

Re: Migration et architecture ZF2

Orkin a écrit:

Salut, je t'avoue que ça commence à être un peu compliqué à suivre.

Je t'avoue que tu n'es pas le seul à trouver ça compliqué. Même moi je m'y perds....

Orkin a écrit:

La première c'est via des variables d'environnement dans ton index.php suivant la variable ça va charger le fichier de configuration associé et/ou les modules qui vont bien mais ça implique d'avoir un fichier application.config.php un peu gros et vite bordélique.

C'est ce que je pensais faire mais je vois que tu confirme que ça risque de vite devenir bordélique au niveau du fichier application.config.php. A réfléchir tout de même...

Orkin a écrit:

J'aurais envi de te proposer une autre approche peut être un peu plus longue à mettre en place car un peu plus de boulot. C'est de développer ton application en mode API/micro-services de ce fait tu vas avoir une grosse application (ou un groupe de plusieurs) qui vont être disponibles.
Pour tes clients tu développes des webapp différentes (dans cette configuration tu peux vraiment tout avoir, application mobile, client JS etc ...) là du coup tu es un peu obligé de mettre de côté le bon vieux site web avec des pages générées côtés serveur. Enfin ça fonctionnera avec mais tu devrais faire des appels à ton api directement dedans donc potentiellement des temps de chargement un peu plus long. Avec ça + une bonne gestion de droit tu seras en mesure de service n'importe quelle application à tes clients. C'est ton application web qui va avoir la logique pour récupérer les informations en fonction des spécificités.

D'après ce que je comprends, l'architecture micro-service nécessite plusieurs serveur pour fonctionner. Est-ce toujours le cas ou un seul serveur peut suffire ?
Par ailleurs, j'ai l'impression que niveau maintenabilité et monitoring, c'est un peut galère comme architecture. Je me trompe ?
Tu as des liens vers des exemples d'architecture micro-service ? Tuto ou autres ?


@flobrflo : merci pour ta réponse. Je vais réfléchir un peux plus par rapport à ce que tu propose comme solution wink

Hors ligne

 

#13 28-07-2015 11:21:59

flobrflo
Membre
Lieu: Marseille
Date d'inscription: 26-04-2013
Messages: 376

Re: Migration et architecture ZF2

Au contraire le système Api te permet d'avoir une très bonne maintenabilité vu qu'elle est commune à tous.
Chacune de tes app va taper dans les même fonctions avec juste un identifiant client différents.
Ce qui te permettra de savoir qui a accès ou pas. (Orkin corrige moi si tu pensais pas à ça ^^)
C'est un peu le principe d'Angular pour le web par exemple.

EDIT: tu peu très bien tout faire sur le même serveur ^^

Dernière modification par flobrflo (28-07-2015 11:25:29)

Hors ligne

 

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages