Comprendre le domaine et constituer l'équipe : les fondements du changement (II)

Se lancer dans un projet complexe nécessite une collecte de contexte complète tout en abordant simultanément les connaissances du domaine sous un angle nouveau, en tirant parti des connaissances des experts du domaine. Cette approche aligne l'équipe technique sur les objectifs commerciaux et établit une feuille de route fondamentale pour une prise de décision éclairée tout au long du cycle de vie du produit.

Les premières sessions de collecte de connaissances avec l'équipe précédente et les utilisateurs actuels de l'application se sont révélées improductives. Nous avons brièvement envisagé de procéder de manière indépendante, malgré les risques inhérents.

EventStorming : Dévoilement du domaine

En tant que responsable technique, j'ai défendu dès le départ une approche axée sur le domaine, compte tenu de la complexité du projet et du besoin d'appropriation de l'équipe. Cela a centré le domaine, favorisant une compréhension partagée (langage omniprésent) qui a rationalisé la communication et facilité la cartographie de l'état actuel de l'application.

Nous avons lancé des sessions EventStorming en utilisant un modèle Miro, fournissant une structure et une légende pour une concentration efficace. Une connaissance préalable des concepts d'EventStorming, que ce soit par le biais d'une préparation pré-session ou d'explications initiales, est très bénéfique.

Notre processus structuré EventStorming comprenait :

1. Exploration des événements de domaine (grande image) : Identifier, classer par ordre chronologique et valider les événements clés du système avec des experts du domaine, en mettant en évidence les lacunes et les dépendances.
2. Raffinement et analyse : Ajouter des notes explicatives, documenter les questions, analyser en profondeur chaque événement et identifier les points de décision critiques.
3. Modélisation de domaine : Identifier les agrégats et les limites, définir les acteurs et les rôles, établir des commandes de déclenchement, documenter les politiques et les règles métier et identifier les déclencheurs d'événements internes/externes.
4. Documentation et validation : Organiser et nettoyer les informations collectées, établir des relations claires, valider le modèle avec les parties prenantes et créer une documentation de référence.

EventStorming a fourni non seulement une compréhension du domaine, mais également une base pour appliquer les principes de la Conception pilotée par domaine (DDD) de manière stratégique et tactique.

Conception stratégique basée sur le domaine

Une première étape cruciale consistait à structurer stratégiquement le domaine. La complexité du système et la nécessité d'un alignement technique/métier ont conduit à l'adoption des principes DDD. La Context Mapping s'est avérée inestimable, même au sein de notre monolithe en attente de refactorisation. Nous avons identifié des Contextes limités, fonctionnant dans un contexte technique unique avec un noyau partagé. Cette analyse, bien que peu approfondie, a guidé le projet vers une architecture orientée domaine, améliorant à la fois le développement technique et la collaboration entre les équipes.

Définition des limites (Contextes délimités)

L'

Identification des Contextes délimités a clarifié les relations entre les systèmes et les systèmes externes, simplifiant la complexité et établissant une base pour une modularisation future. Ces décisions initiales guideront la décomposition du monolithe en composants gérables alignés sur des contextes définis. Cela a également facilité la priorisation et l’identification des domaines nécessitant une simplification, un découplage ou une élimination. Nous nous sommes concentrés sur la mise en œuvre de Couches anti-corruption (ACL) pour l'interaction avec le système externe, préservant ainsi l'intégrité du système.

Cinq contextes clés ont été identifiés :

• Affectation des commandes
• Génération d'étiquettes
• Préparation des commandes
• Intégration du commerce électronique
• Préparation des commandes groupées

Ces décisions ont favorisé une architecture durable et aligné le développement sur les besoins de l'entreprise.

Langue omniprésente

L'établissement d'un langage robuste et omniprésent s'est avéré vital. Les avantages d'un langage partagé, créé grâce à la collaboration entre experts du domaine et développeurs, dépassent de loin les efforts de traduction ou les erreurs d'interprétation. Cette ressource vivante a mis en relation l'équipe technique avec des experts du domaine, améliorant ainsi la communication, réduisant les malentendus et garantissant une représentation précise du domaine dans le code. Cela a favorisé des solutions techniques efficaces et adaptées aux besoins de l'entreprise.

Conception tactique basée sur le domaine

En suivant le cadre stratégique, nous avons mis en œuvre les principes tactiques DDD pour structurer le code, reflétant la réalité du domaine et garantissant la durabilité à long terme.

Entités et objets de valeur

Comprendre la distinction entre les entités et les objets de valeur est crucial.

Entités

Les entités possèdent une identité unique et persistante, même avec des changements d'attributs. Les exemples incluent :

• Commander
• Produit
• Transporteur
• Boutique
• Client

Objets de valeur

Les objets de valeur manquent d'identité individuelle ; leur valeur les définit. Des attributs identiques signifient une équivalence. Ils sont immuables et idéaux pour encapsuler les concepts apparaissant dans le domaine. Les exemples incluent :

• RéférenceProduit
• ProduitEan13
• Référence de commande
• Prix
• Poids
• Numéro d'expédition

Cette approche a créé un code plus compréhensible et modulaire avec des responsabilités clairement définies.

Exemple d'objet de valeur :

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Services

Les services sont classés par objectif et modèles mis en œuvre.

Services de domaine

Les services de domaine encapsulent une logique métier qui ne correspond pas à des entités ou des valeurs, fonctionnant strictement selon les règles du domaine sans dépendances d'infrastructure.

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Services applicatifs

Les services d'application coordonnent les opérations du domaine avec les interactions externes, centralisant les opérations complexes et séparant le domaine et l'infrastructure. Ceux-ci incluent les cas d'utilisation, les gestionnaires de commandes et les gestionnaires d'événements.

Services d'infrastructures

Les services d'infrastructure gèrent les interactions avec les composants externes (bases de données, systèmes de fichiers, etc.), agissant comme des adaptateurs pour maintenir l'agnosticisme du domaine.

<code class="language-php"><?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}</code>

Classification des services

Les services sont classés par fonction et modèles de conception associés : transformateurs, constructeurs, usines, présentateurs, notificateurs, validateurs et clients.

Cette modélisation initiale du domaine, bien qu'incomplète et itérative, a favorisé la participation et l'engagement des équipes. D'autres raffinements et restructurations étaient attendus.

Ressources DDD recommandées :

• "Conception basée sur le domaine : s'attaquer à la complexité au cœur du logiciel" par Eric Evans
• "Mise en œuvre de la conception basée sur le domaine" par Vaughn Vernon
• "Conception basée sur le domaine en PHP" par Carlos Buenosvinos, Christian Soronellas et Keyvan Akbary

Construire l'équipe : les étapes de Tuckman

L'adoption du DDD a suivi la formation d'équipes, en suivant les étapes de Tuckman (Forming, Storming, Norming, Performing).

Formage

Les membres de l'équipe initiale ont examiné le projet, documenté les opérations et établi les bases techniques et organisationnelles (processus, normes, outils).

Assaut

Des désaccords mineurs ont conduit à définir des styles de travail, des méthodes de communication et des processus de prise de décision.

Normation

Des accords d'équipe, des normes de codage, des processus de développement, des limites WIP, des règles de déploiement, une gestion de la dette technique et des ADR ont été établis.

Performant

Le cadre établi a permis un développement de produits efficace, en donnant la priorité aux initiatives précieuses et en favorisant une culture d'amélioration continue.

Documentation : Le modèle Diataxis

La documentation a été gérée à l'aide de GitLab Pages et Jekyll avec le thème Just the Docs, suivant le modèle Diátaxis : Tutoriels, Guides, Explications et Références. L'automatisation de la documentation à l'aide d'Event Catalog et d'AsyncAPI était prévue mais pas entièrement mise en œuvre.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!