Laravel orienté domaine

Tout d'abord, je tiens à clarifier que le terme "domaine" qu'on utilise est effectivement lié au paradigme de programmation DDD (Domain Driven Design), également connu sous le nom de "conception orientée domaine" en français.

Bien que notre utilisation du mot "domaine" ne soit pas identique à celle du DDD, il existe plusieurs similitudes entre les deux concepts. Si vous êtes familier avec le DDD, vous remarquerez ces similitudes tout au long de ce article. J'ai pris soin de mentionner tout chevauchement et différence pertinents. Maintenant, parlons des domaines.

Les domaines qu'on décrit pourraient également être appelés groupes, modules ou même services selon les préférences de chaque individu. Quel que soit le nom choisi, les domaines désignent un ensemble de problèmes métier spécifiques que vous cherchez à résoudre. Pour illustrer cela, prenons l'exemple d'une application de gestion des réservations d'hôtel.

Dans cette application, différents domaines seraient impliqués, tels que la gestion des clients, la gestion des réservations, la facturation, la gestion des inventaires d'hôtel, et ainsi de suite. Chaque domaine représente une partie essentielle du système, avec ses propres règles métier et sa logique spécifique. L'approche DDD vous permettra de concevoir ces domaines de manière indépendante, en les organisant autour de la logique métier pour une meilleure compréhension et maintenabilité du code.

En adoptant une approche Domain Driven Design, vous pourrez structurer votre application de manière à refléter fidèlement les différents domaines et à optimiser leur gestion, tout en offrant une meilleure extensibilité et évolutivité du système dans son ensemble. Cela permettra de créer des applications Laravel plus puissantes, mieux alignées sur les besoins spécifiques de chaque domaine et plus facilement maintenables à mesure que votre application évolue.

Les frameworks web modernes vous encouragent souvent à répartir différents concepts liés dans divers endroits de votre code : les contrôleurs avec les contrôleurs, les modèles avec les modèles, et ainsi de suite. Cependant, lorsqu'un client vous demande de travailler sur un projet, il ne vous demande pas de "travailler sur tous les contrôleurs maintenant" ou de "passer du temps dans le répertoire des modèles". Au lieu de cela, ils expriment leurs besoins liés à des fonctionnalités spécifiques telles que la facturation, la gestion des clients ou les fonctionnalités de réservation. Ces groupes de concepts liés sont ce que j'appelle des domaines.

Les domaines ont pour objectif de rassembler les différents éléments d'un projet qui sont étroitement liés entre eux. Bien que cela puisse sembler évident au premier abord, la gestion des domaines est en réalité plus complexe qu'on ne le pense. C'est pourquoi une partie de ce article se concentrera sur l'établissement de règles et de pratiques pour maintenir votre code bien organisé, en mettant l'accent sur les domaines.

Il est important de noter qu'il n'existe pas de formule mathématique universelle que je puisse vous donner pour organiser vos domaines. La façon de structurer vos domaines dépend largement du projet spécifique sur lequel vous travaillez. Ainsi, ce arricle ne propose pas de règles fixes, mais plutôt une collection d'idées que vous pouvez utiliser et adapter selon vos préférences et les besoins de chaque projet.

Considérez cette approche comme une opportunité d'apprentissage, plutôt que comme une solution unique à appliquer à tous les problèmes que vous pourriez rencontrer. En comprenant comment organiser vos domaines de manière efficace, vous pourrez développer une compréhension approfondie de la conception orientée domaine et améliorer la qualité et la maintenabilité de vos applications Laravel.

Domaines & applications

Vous avez raison, regrouper des idées ensemble dans des domaines peut être une pratique utile, mais la question cruciale est de déterminer jusqu'où nous devons aller avec cette approche. Prenons l'exemple des factures, où nous pourrions regrouper tous les éléments liés aux factures tels que les modèles, les contrôleurs, les ressources, les règles de validation, les jobs, etc.

Cependant, dans les applications HTTP classiques, il n'y a souvent pas de correspondance stricte un-à-un entre les contrôleurs et les modèles. Bien que dans les API REST et la plupart des contrôleurs CRUD classiques, il puisse exister une correspondance un-à-un, il y a des exceptions qui posent problème. Par exemple, les factures ne peuvent pas toujours être traitées de manière isolée ; elles dépendent d'un client auquel elles doivent être envoyées, ou d'une réservation pour être correctement facturées, et ainsi de suite.

C'est là qu'une distinction plus poussée entre le code de domaine et le code qui l'utilise se révèle essentielle.

D'un côté, nous avons le domaine, qui englobe toute la logique métier spécifique à notre application. De l'autre côté, nous avons du code qui utilise - consomme - ce domaine pour l'intégrer avec le framework et le rendre accessible à l'utilisateur final. Les applications jouent un rôle crucial en fournissant l'infrastructure nécessaire pour que les utilisateurs finaux puissent utiliser et manipuler le domaine de manière conviviale.

En séparant clairement le code de domaine du code d'infrastructure, nous améliorons la lisibilité, la maintenabilité et la compréhension globale de notre application. Le code de domaine devient plus indépendant et portable, tandis que le code d'infrastructure facilite l'interaction avec le framework et fournit une interface utilisateur conviviale.

Cette distinction claire entre domaine et infrastructure est l'une des pierres angulaires du DDD. En adoptant cette approche dans le contexte de Laravel, vous pouvez construire des applications plus évolutives et mieux organisées, tout en favorisant une meilleure collaboration entre les membres de l'équipe travaillant sur différents aspects du projet.

En pratique

Concrètement, dans l'approche DDD appliquée à Laravel, votre code sera organisé de manière à séparer clairement le domaine des autres aspects de l'application. Voici à quoi cela pourrait ressembler :

Le Domaine : Le domaine contiendra toutes les classes et la logique spécifiques à votre métier. Cela comprendrait des éléments tels que :

• Modèles : Représentent les entités métier et leur état.
• Constructeurs de requêtes : Facilitent la construction de requêtes complexes pour interagir avec la base de données.
• Événements de domaine : Permettent de réagir à des événements spécifiques liés au domaine.
• Règles de validation : Définissent les règles de validation des données du domaine.

Dans cette approche, le domaine est indépendant et ne dépend pas directement du framework. Il peut être testé de manière isolée et réutilisé dans d'autres parties de l'application.

La Couche Application : La couche application contient une ou plusieurs applications qui utilisent le domaine pour fournir des fonctionnalités spécifiques. Chaque application peut être considérée comme une application isolée, avec son propre ensemble de fonctionnalités. Ces applications ne communiquent généralement pas directement entre elles. Exemples d'applications :

• Un panneau d'administration HTTP standard : Cela peut être une application utilisée par les administrateurs pour gérer différents aspects du système, comme la gestion des utilisateurs, la gestion des commandes, etc.
• Une API REST : Une application qui expose des endpoints pour permettre aux clients externes d'interagir avec le système.
• La console (Artisan de Laravel) : Une application en ligne de commande qui fournit des commandes pour effectuer diverses tâches.

Chaque application utilise le domaine pour exécuter les opérations métier requises, mais l'infrastructure de chaque application est spécifique à son contexte (par exemple, les contrôleurs dans une application HTTP).

En structurant votre code de cette manière, vous améliorez la séparation des préoccupations et la maintenabilité de votre application. Le domaine reste concentré sur la logique métier tandis que les applications offrent des interfaces utilisateurs spécifiques pour interagir avec ce domaine.

À titre de vue d'ensemble à haut niveau, voici à quoi pourrait ressembler la structure des dossiers d'un projet orienté domaine :

One specific domain folder per business concept

app/Domain/Invoices/

    ├── Actions

    ├── QueryBuilders

    ├── Collections

    ├── DataTransferObjects

    ├── Events

    ├── Exceptions

    ├── Listeners

    ├── Models

    ├── Rules

    └── States

app/Domain/Customers/

    // …

Les namespaces :

La gestion des namespaces est un aspect important lorsqu'il s'agit d'organiser votre code en utilisant le paradigme DDD dans Laravel. Comme vous l'avez mentionné, la convention Laravel par défaut utilise l'espace de noms racine "\App" pour tout le code de l'application.

Cependant, étant donné que DDD encourage à penser en termes de groupes de concepts métier liés plutôt qu'en termes de groupes de code partageant des propriétés techniques, vous pouvez choisir de personnaliser la structure des espaces de noms pour mieux refléter cette approche.

Par exemple, si vous préférez rester proche de la structure par défaut de Laravel, vous pouvez utiliser des espaces de noms tels que \App\Domain et \App\Api pour séparer les différentes parties de votre application.

D'un autre côté, si vous souhaitez une séparation plus claire entre les groupes de concepts métier, vous pouvez modifier le fichier composer.json pour spécifier des espaces de noms racine supplémentaires :

{

    // …

    "autoload" : {

        "psr-4" : {

            "App\\" : "app/App/",

            "Domain\\" : "app/Domain/",

            "Support\\" : "app/Support/"

        }

    }

}

Dans cet exemple, nous avons ajouté deux nouveaux espaces de noms racine : Domain\ pour regrouper les classes liées au domaine et Support\ pour stocker des utilitaires ou des classes qui n'appartiennent pas à un domaine spécifique.

L'essentiel est de commencer à penser en termes de groupes de concepts métier liés et d'organiser votre code en conséquence, en utilisant des namespaces appropriés pour refléter cette organisation. Cela facilitera la compréhension et la maintenabilité de votre application à mesure qu'elle se développe.

Les outils existants

Le paquet Laravel DDD proposé par "Lunarstorm" est une ressource précieuse pour les développeurs cherchant à appliquer les principes de conception orientée domaine dans leurs projets Laravel. Ce paquet fournit une structure de base et des conventions pour organiser votre code en suivant les principes du DDD, permettant ainsi une meilleure séparation des responsabilités et une meilleure gestion des domaines.

Lien GitHub : https://github.com/lunarstorm/laravel-ddd/tree/main

En utilisant ce paquet, vous pouvez créer une architecture solide pour vos applications Laravel, en divisant le code en domaines distincts, chacun étant responsable d'une partie spécifique de la logique métier. Grâce à une séparation claire entre le domaine et la couche application, votre code sera plus lisible, évolutif et facilement testable.

En plus de fournir des directives sur la structure du code, le paquet offre également des exemples concrets et des bonnes pratiques pour l'implémentation de certains concepts clés du DDD, tels que les entités, les valeurs d'objet, les agrégats, les services de domaine, etc.