Structure de projet : Une approcher métier ?

La structure d'un projet est souvent peu ou pas réfléchie d'un point de vue métier. Il y a peu, j'ai assisté à une présentation de Sandro Mancuso sur ce sujet. Or il y a beaucoup à dire sur le sujet !

Une question bête, mais pas stupide !

L'approche initiale est basée sur la découverte d'un projet existant et une question simple :
La question est simple, mais il n'est pas forcément facile d(y répondre de manière détaillée. En particulier, quand on est en mode "découverte" sur les sources !
Le découpage "classique" d'un projet étant calqué sur le modèle MVC, on se retrouve en général avec trois dossiers principaux :

• Contrôleur
• Modèle
• Vue

Dans un projet Symfony 2(PHP), ceux-ci s'appellent Controller/Entity/Resources.
Cette structure de projet est orientée "développeur"/technique. Celle-ci est très efficace pour... un développeur. Cependant, pour une personne de type "fonctionnel", c'est un peu plus compliqué !
En fonction de la taille du projet, on va avoir deux sources d'information :

1. Le nom des objets, des contrôleurs et des vues.
2. Le nom des sous-répertoires représentant un groupe de fonctionnalités

Note : les "gros" projets ont tendance à avoir un produit cartésien (domaines métiers,domaines techniques). Personnellement, j'ai vu beaucoup de projets ayant les domaines techniques priorisés par rapport aux domaines métier. Les principales exceptions étant les applications découpées en module.

Avec ces informations, on sait en gros le sujet de l'application, mais à moins d'aller regarder dans chaque contrôleur, il va être compliqué de savoir ce qu'elle faire réellement !
Exemple : Une application ayant des utilisateurs et des livres comme objets métier. Allez savoir si l'application fait de la location ou de la vente de livre.

Une arborescence différente !

Sur cette réflexion Sandro Mancuso propose une arborescence légèrement différente :

• Action (Dossier contenant les actions métier réalisables par l'application)
• Modèle (Dossier contenant l'ensemble des entités métier nécessaires à réaliser les actions)
• Restitution (Dossier contenant la partie vue et la partie contrôleur)

Note :
Celle-ci est réalisée de mémoire et simplifiée pour le bille.!
On a toujours l'arborescence technique à l’intérieur de cette arborescence métier, si celle-ci est nécessaire.

Jusqu'à ce point, on a une nouvelle arborescence pour le projet. Mais rien de très impactant. Cependant, cette arborescence s’associe à quelques idées simples :

• L'utilisateur interagit avec le système seulement avec la partie restitution.
• Le contrôleur interagit avec le modèle seulement via les actions.
• Une action par fichier.
• Le nom de l'action est un verbe (ou en contient un), c'est une action !

Cela fait qu'un projet respectant ce type d'architecture est relativement simple à découvrir. Il suffit d'aller voir le dossier Action et ses éventuels sous-dossiers et de lire la liste des actions disponibles.
Exemple : Une application avec les actions UtilisateurAcheterLivre UtilisateurVendreLivre. On a une application qui gère la vente de livre et la reprise de livre usagé.

Sandro Mancuso a aussi parlé de la structure interne de la partie Modèle (Séparation des domaines métier, règle de non-ingérence etc...). Mais n'étant pas la partie qui m'intéresse, vous n'en aurez pas plus sur cet sujet. Sachez simplement qu'elle existe !

Ma réflexion personnelle sur la question...

Après réflexion, cette structure/arborescence me semble naturelle. Pour moi, cela s'associe à un Design Pattern que j'aime beaucoup "Le processeur de commande" (Command Pattern). C'est ce qui permet de gérer le do/undo dans les applications. Or avoir à disposition ce comportement sur l'ensemble du domaine métier d'une application est particulièrement agréable.

D'ailleurs l'un de mes vieux projets étudiants l'équivalent du dossier "Action" : Projet Api Java Labyrinthe Game
Vous pouvez y jeter un œil et me dire si vous arrivez à voir de quoi parle l'application. Malgré... le mauvais nommage et le manque de sous-dossier !

Mais, c'est probablement parce que je suis vieux jeu. Pour en avoir discuté avec un collègue, cela se prête aussi à la "Programmation événementielle". Genre... les applications microservices basées sur l'échange de message (JMS/ Queue).
L'argument principal étant qu'il est totalement possible retrouver l'état de l'application à tout moment :

• Pour un crash de données et qu'il est nécessaire de rejouer le métier réalisé après la dernière sauvegarde de base de données.
• Pour reproduire un bogue spécifique.
• Pour mettre à jour une base de recettes par rapport à la production.
• Pour les tests métier.

Vu de ma porte un "message" n'est qu'une commande qui s'est fait sérialiser. Ce qui fait que je comprends très bien le point de vue de mon collègue.

Conclusion :

Dans tous les cas, j'ai trouvé la réflexion de Sandro Mancuso sur la structure/arborescence d'un projet très intéressante. En particulier, parce qu'on ne se pose pas ou plus cette question. Or c'est sur cela que l'on construit tous les jours nos applications. J'espère que vous penserez à ce billet lors de la création de votre prochain projet et que vous vous poserez la question.

Cordialement,
Patrick Kolodziejczyk.

Source :
http://craftedsw.blogspot.fr/
http://www.developpez.net/forums/blo...est-practices/
http://www.developpez.net/forums/blo...principe-base/
http://sourceforge.net/projects/labygame/