Technical Tutorials

Les systèmes logiciels évoluent. À mesure qu'ils s'étendent, la complexité de la logique métier qu'ils doivent supporter augmente. Lorsque les règles métier s'entremêlent aux détails d'implémentation technique, les bases de code deviennent fragiles et ingérables. C'est ici qu'intervient le Domain-Driven Design (DDD). Le DDD n'est pas seulement un ensemble de patrons ; c'est une approche qui privilégie le domaine central et la logique métier, construisant des structures complexes sur la base d'une compréhension approfondie du métier.

Le langage ubiquitaire : Combler le fossé

Avant de plonger dans les structures techniques, nous devons établir l'aspect le plus critique du DDD : le langage ubiquitaire. Il s'agit d'un langage partagé utilisé à la fois par les développeurs et les experts du domaine (les parties prenantes métier). Il élimine les erreurs de traduction où le terme « commande » signifie une chose pour les ventes et autre chose pour la logistique.

En veillant à ce que les noms dans le code correspondent à la terminologie métier, nous créons une documentation vivante qui reste pertinente. Si un terme métier change, le code devrait probablement changer avec lui.

Contextes bornés : Gérer la complexité à grande échelle

À mesure que les domaines s'agrandissent, un seul langage ubiquitaire devient souvent insuffisant. C'est ici que les Contextes bornés entrent en jeu. Un contexte borné définit une limite dans laquelle un modèle spécifique s'applique et le langage ubiquitaire est valide. Un même concept peut avoir des significations différentes selon les contextes. Par exemple, un « Compte » dans un contexte bancaire peut faire référence à un profil client, tandis que dans un contexte de facturation, il désigne un écriture dans un registre financier.

Découpler ces contextes permet aux équipes de travailler indépendamment et de choisir les solutions techniques les plus adaptées pour chaque sous-domaine.

Agrégats : Limites de cohérence

Au sein d'un contexte borné, nous organisons notre modèle de domaine à l'aide d'Agrégats. Un agrégat est un groupe d'objets associés que nous traitons comme une unité pour les modifications de données. Il se compose d'une Racine d'Agrégat et de ses entités internes.

La règle clé est la suivante : les objets externes ne peuvent détenir que des références à la Racine d'Agrégat, jamais aux objets internes. Cela garantit l'intégrité transactionnelle et la cohérence. Lorsque vous mettez à jour un agrégat, vous le mettez à jour dans son ensemble.

Exemple : Un Agrégat de Commande


public class Order {
    private List items;
    private CustomerId customerId;
    private Money totalAmount;

    public void addItem(ProductId productId, int quantity) {
        // Logique métier pour ajouter un article
        this.items.add(new OrderItem(productId, quantity));
        this.recalculateTotal();
    }

    public void cancel() {
        if (this.items.isEmpty()) {
            throw new IllegalStateException("Cannot cancel an empty order");
        }
        // Déclencher un événement de domaine
        this.raiseEvent(new OrderCanceledEvent(this.id));
    }

    private void recalculateTotal() {
        this.totalAmount = this.items.stream()
            .map(item -> item.getPrice().multiply(item.getQuantity()))
            .reduce(Money.ZERO, Money::add);
    }
}

Dans cet exemple, Order est la Racine d'Agrégat. OrderItem est une Entité au sein de l'agrégat. Remarquez comment la méthode cancel applique les règles métier en interne, protégeant ainsi la cohérence de l'agrégat.

Entités vs Objets de Valeur

Une distinction cruciale dans le DDD est celle entre les Entités et les Objets de Valeur :

Les Entités possèdent une identité unique qui persiste dans le temps, même si leurs attributs changent (par exemple, un ID de Commande).
Les Objets de Valeur sont immuables et définis par leurs attributs. Deux objets de valeur sont égaux si toutes leurs propriétés sont égales (par exemple, un objet Money ou un EmailAddress).

L'utilisation d'Objets de Valeur pour des propriétés comme l'argent ou les adresses empêche les états invalides et rend le modèle de domaine plus riche et plus expressif.

Événements de domaine : Découpler les effets secondaires

Les domaines complexes nécessitent souvent des effets secondaires, tels que l'envoi d'un e-mail ou la mise à jour d'un stock. Au lieu de coupler ces actions directement à la logique métier, nous utilisons des Événements de domaine. Il s'agit de notifications indiquant qu'un événement significatif s'est produit dans le domaine.

Dans l'exemple de code ci-dessus, nous avons vu raiseEvent(new OrderCanceledEvent(this.id)). Cela découple l'acte d'annulation du processus de notification. Un gestionnaire d'événements séparé peut écouter OrderCanceled et effectuer les actions en aval nécessaires sans encombrer l'agrégat Order.

Conclusion

Le Domain-Driven Design est une approche puissante pour construire des systèmes logiciels complexes. En se concentrant sur les contextes bornés, en imposant la cohérence des agrégats, en tirant parti des entités et des objets de valeur, et en utilisant les événements de domaine, nous pouvons créer des systèmes qui sont non seulement techniquement robustes, mais aussi profondément alignés avec les objectifs métier. Bien que la courbe d'apprentissage soit raide, les avantages à long terme en termes de maintenabilité, d'évolutivité et de communication plus claire entre les équipes techniques et métier sont inestimables.