En vous concentrant uniquement sur la réalisation, le type de langage à utiliser, la structure de base de données à choisir, vous pouvez vite oublier votre objectif premier : comment ma solution peut être la plus pratique, utile et ergonomique possible pour ses utilisateurs ?
En effet, il est primordial de garder à l'esprit que le code n'est pas une fin en soi : il est une manière de réaliser une solution à apporter à des utilisateurs. Pour cela, le développeur doit comprendre les enjeux, en gardant toujours à l'esprit les besoins des personnes qui vont utiliser la solution.
Et croyez-moi, avec cette démarche, tout le monde est gagnant : le client en sort content, il a besoin de faire moins de corrections et de modifications, ce qui vous demande moins de temps, moins d'échanges fastidieux, et surtout moins de frustration. 😎
D'accord, j'ai compris ! Je veux satisfaire mes utilisateurs. Mais comment faire ?
Pour avoir une chance de réussir, l'un des moyens consiste à collaborer avec les acteurs impliqués dans la construction du produit à l'aide du Domain-Driven Design, pour créer et utiliser un modèle de domaine.
Découvrez le modèle de domaine
Un modèle de domaine est une représentation conceptuelle des éléments clés qui doivent être compris par tous, pour créer la solution souhaitée par le client. Vous pouvez le considérer comme l'idée qui constitue le fondement même d'un programme, mais qui serait compréhensible à la fois par les parties prenantes et par les développeurs.
Mais qu'est-ce que c'est, un élément clé ?
Pensez au dernier film que vous avez vu. Si vous deviez le résumer à quelqu'un, qu'est-ce que vous diriez, et que laisseriez-vous de côté ? Pour faire simple, si vous en parlez, c'est un élément important, ou élément clé.
En revanche, si vous le laissez de côté, il est moins important : c'est un élément qu'on appelle mineur. Le ou les principaux personnages sont importants. Les obstacles qu'ils doivent franchir, également. Le fait que le personnage doive se rendre sur Tatooine, aussi. Mais qu'il porte une veste couleur blanc cassé ne l’est pas. Ce regroupement d'éléments clés est votre domaine.
Si votre film a une suite (ou devient même une trilogie), certains éléments s'ajouteront aux éléments clés de votre premier domaine. Mais comme il s'agit d'une toute nouvelle histoire, certains éléments devront être à part : cela deviendra un domaine à part entière.
Wow, est-ce qu’on peut se poser deux minutes ? Cela veut dire qu'il peut y avoir plus d'un domaine dans un modèle de domaine ?
Eh oui ! Dans le cas de modèles de domaine complexes, vous regrouperez les différents éléments dans des domaines distincts. On les appelle contextes délimités (boundedcontext, en anglais).
Mais comment ça marche ?
Voici un exemple que vous connaissez bien : une salle de classe. Disons que vous allez écrire un logiciel pour une école.
Avant de commencer, vous savez déjà comment une classe fonctionne. Facile, n’est-ce pas ? Elle se passe dans une salle, des jours donnés. Il y a également son enseignant attitré, ainsi que les élèves qui suivent le cours. Les devoirs, les évaluations, les contrôles et les notes doivent être enregistrés. Toute cette infrastructure doit être gérée par votre programme. Hé, c'est logique ! 🤓
Mais, alors que vous pensiez que tout était prêt, lors d’un échange, quelqu’un aborde l'aspect financier. Mais oui ! L’enseignant doit être payé, ainsi que la facture d'électricité de la salle. Les mêmes concepts (élèves, enseignant, salle de classe) commencent donc à avoir des significations supplémentaires. Eh oui, ça se complique déjà.
Comment organiser toutes ces informations, qui commencent à être complexes, pour que je puisse créer une application ?
La réponse peut paraître simple, mais rien de plus efficace : en les décomposant en domaines distincts ! Vous avez découvert deux domaines (pour le moment...) : la logistique et les finances. Nous verrons bientôt que chaque domaine a un point de vue unique sur des concepts identiques.
La meilleure manière de gérer un programme est d’adopter une approche basée sur le client, ou descendante. De cette manière, vous essayez de comprendre le quoi et le pourquoi de la solution que vous devez créer, au lieu de vous focaliser sur comment la créer. Votre modèle de domaine décrit ces concepts clés de « quoi ? » et « pourquoi ? » et les énonce dans des termes que chacun peut comprendre.
Mais pourquoi est-ce si important ?
Je vais vous montrer. Tentons l'expérience en jouant les rôles d'un client (moi) et d'un développeur (vous). Voyons si nous pouvons trouver la même définition pour quelque chose de simple : un livre. Réfléchissez. Qu'est-ce qu'un livre ? Allez-y, prenez une feuille, ou ouvrez un nouvel onglet dans votre navigateur favori. Et écrivez une définition : qu’est-ce qu’un livre ?
C'est bon pour vous ?
D'accord, alors voici ma réponse : un objet physique qui peut être emprunté à la bibliothèque.
Euuuuuuuh “la bibliothèque” ? Pardon, mais à quel moment ?! 🤨 Vous ne m'aviez donné aucun contexte. Comment aurais-je pu trouver votre définition ?
Exactement !! Maintenant, vous savez pourquoi il est si difficile d'écrire du code pour satisfaire les clients, sans collaborer avec eux. Vous avez besoin de comprendre la terminologie et le contexte de vos clients. Même des termes simples peuvent avoir un sens différent, particulièrement quand il s’agit de différentes personnes dans des contextes différents. La clé, c'est la discussion : ne faites pas de suppositions !
Découvrez à quoi ressemblent les modèles de domaine
Il y a plusieurs façons de représenter un modèle de domaine. Cela peut prendre la forme d'une liste à puces sur des pages wiki, ou être plus formel. L'un des moyens les plus courants consiste à utiliser des diagrammes.
Créez votre premier diagramme de domaine avec la pop culture
Ici, nous sommes bien dans une logique descendante, contrairement à un modèle du domaine du point de vue du programme, ou approche ascendante, qui s'intéresse à comment créer. À ce stade, nous ne nous préoccupons ni de bases de données, ni d'objets, de déploiements cloud ou de toute autre réalisation technique.
Ce diagramme (ainsi que celui de la rubrique ci-dessous) a été créé à l'aide du langage partagé de modélisation (Unified Modeling Language), également appelé UML ! Vous apprendrez comment créer votre propre langage et à l’utiliser dans la deuxième partie de ce cours.
Tirez profit du Domain-Driven Design
Alors, vous commencez à saisir l’utilité d'un modèle de domaine ? Le plus grand avantage est que les développeurs comprennent le programme du point de vue métier. Comprendre le métier, c’est comprendre comment l'entreprise gagne de l'argent tout en conservant et en gagnant des clients. Or, une entreprise évolue en permanence. Comme elle cherche à conserver ses clients et à en acquérir de nouveaux, elle va imaginer des fonctionnalités qui feront le bonheur de ces mêmes clients.
Nous en arrivons donc au deuxième avantage principal du Domain-Driven Design : si vous créez une application du point de vue d'un domaine, les modifications sont plus faciles à mettre en œuvre. Examinons un autre exemple :
Parlons taxis.
Ce diagramme illustre les éléments clés associées à une société de taxis. Vous voyez que la notion de Course est au cœur de notre modèle. Les Clients les demandent. Les Chauffeurs en Voiture les fournissent. En outre, un paiement est effectué à chaque course, qui dépend des Lieux.
À présent, regardez l'élément Paiement dans le modèle de domaine. Il reste assez général. Il ne précise pas « Espèces » ou « Carte de crédit ». Si vous vouliez permettre de payer en crypto-monnaie, ce serait tout à fait possible. Cela permet de laisser la logique métier déterminer si les clients souhaitant régler de cette façon sont assez nombreux pour implémenter une fonctionnalité qui leur est dédiée.
À votre tour !
Maintenant, c'est à vous de modéliser une situation ! Réfléchissez à un livre que vous avez lu récemment, ou à un de vos livres favoris que vous avez lu plusieurs fois, et dont vous vous souvenez bien. Créez un modèle de domaine de ce livre.
Je ne sais pas encore modéliser ! Comment faire ?
Nous n'avons pas encore étudié les approches de modélisation à proprement parler, alors concentrez-vous sur le processus de réflexion. Une simple liste suffira ou, si vous connaissez les diagrammes UML, vous pouvez essayer d'en faire un. Utilisez le format que vous souhaitez ! Votre modèle devra inclure les personnages importants, les lieux et les événements qui se produisent.
Voici un bref exemple :
Harry ;
Ron ;
Hermione ;
pierre philosophale ;
Poudlard ;
Voldemort ;
magie.
À partir de ces éléments-clés, je suis sûre que vous pouvez deviner que mon histoire était Harry Potter à l’école des sorciers ! Maintenant, réglez votre minuteur sur 10 minutes et listez les éléments clés de votre histoire favorite.
En résumé !
Ne vous jetez pas dans le code tête baissée ; commencez par construire des modèles.
Un modèle de domaine capture les éléments essentiels d'un système. Il facilite la communication avec les clients à propos de leurs besoins, et donc la conception de logiciels complexes qui deviennent plus faciles à appréhender.
Un modèle de domaine peut avoir plusieurs domaines ou contextes délimités.
Le modèle de domaine peut prendre de nombreuses formes ; par exemple : diagrammes UML, pages wiki et le code lui-même.
Focalisez-vous sur les questions “quoi” et “pourquoi” quand vous créez un modèle, et pas “comment”.
Maintenant que vous savez ce qu'est un modèle de domaine, nous apprendrons dans le prochain chapitre quelles sont les étapes nécessaires pour esquisser votre modèle.
