En tant que Software Designer, quels sont les modèles mentaux que j’utilise pour concevoir les logiciels que je construit, test et opère ? Le premier modèle mental est de séparer trois grandes responsabilités : Ce que va manipuler mon système, son domaine. Comment va être appelé mon système, ses appelants. Comment mon système appellent d’autres systèmes ou composants d’infrastructure dont il a besoin, ses appellés.
Pourquoi ?
Nous avons besoin d’abstractions / de concepts qui soient adaptées au problème que l’on souhaite résoudre. On ne conçoit pas de la même manière du logiciel desktop, serveur, avec beaucoup d’algorithmie et des structures de données spécialisées, ou de l’informatique de gestion où nos logiciels manipulent des concepts du domaine.
Le domaine
Commençons par le domaine, je passe tout “concept” énoncé par l’expert métier auquel je suis confronté ou que je crée avec une première grille d’analyse :
- Le nommer et lui donner une définition
- Etudier son cycle de vie (s’il en a un, c.f. Entity vs Value)
- Etudier sa structure, ses attributs. Si c’est une entité, comment l’identifier et les opérations permettant de lui attribuer un identifiant et définir les opérations d’unicité/égalité.
- Etudier ses opérations, changements d’états pour une entité et la ou les machines à états qui décrivent toutes ses transitions , opération de dérivation pour entité ou vleur
- Les règles qui régissent ses opérations, changement d’état et structure.
- Des exemples ! si possible dans des scénarios d’usage en utilisant le formalisme Gherkin (Given / When / Then) Bien sûr un domaine complet nécessite des descriptions plus détaillées mais les concepts manipulés sont le point de départ. Les autres concepts nécessaires : Les nomenclatures (valeur qui “classifie”) et les référentiels (entités très stables), les Command / Query / Event en entrée et sortie du système qui décrivent les interactions appelant / appelé. Des modules afin d’encapsuler et organiser l’ensemble des concepts dans des regroupements qui ont du sens. Et les modules ont des dépendances entre eux. L’ensemble de ces éléments constitue un modèle du domaine que l’on regroupe dans un Bounded Context : un “tout” cohérent dont la sémantique est partagée par un groupe identifié de personnes.
Les appelés Un domaine peut appeller d’autres composants dans ses opérations (qu’ils vaut d’ailleurs mieux cantonner dans des commandes notamment si on attend une réponse suite à un changement d’état dans un composant externe). Notre domaine va “abstraire” ces composants derrière des interfaces qui vont exposer des “opérations” sous forme de command ou query et surtout nous retourner des structure de données en réponse.
Future of software development is better context
Séparation des responsabilités entre : appelé domain appelant