Domain Driven Design (DDD)

Le Domain Driven Design (DDD) est une méthodologie de conception logicielle introduite par Eric Evans en 2003. Cette approche privilégie une modélisation profonde du domaine métier et encourage une collaboration continue entre développeurs et experts métier pour créer un langage commun et des modèles partagés. Le DDD transforme la complexité métier en architecture logicielle maintenable et évolutive.

Fondements du Domain Driven Design

• Ubiquitous Language : un langage partagé entre développeurs et experts métier qui se reflète directement dans le code
• Bounded Context : délimitation claire des frontières de chaque sous-domaine avec ses propres modèles et règles
• Strategic Design : vision architecturale globale organisant les relations entre contextes et identifiant le Core Domain
• Tactical Patterns : patterns de conception (Entities, Value Objects, Aggregates, Repositories) structurant le code métier

Avantages du DDD

• Alignement métier-technique : réduction du fossé entre besoins métier et implémentation technique
• Maintenabilité accrue : code expressif reflétant fidèlement les processus métier et facilitant les évolutions
• Gestion de la complexité : découpage en bounded contexts permettant de maîtriser des domaines métier sophistiqués
• Réutilisabilité : modèles métier bien définis pouvant être adaptés à différents contextes
• Communication améliorée : langage ubiquitaire éliminant les ambiguïtés et malentendus entre équipes

Exemple concret : Système de réservation

// Bounded Context: Booking

// Value Object
class BookingPeriod {
  constructor(
    public readonly startDate: Date,
    public readonly endDate: Date
  ) {
    if (startDate >= endDate) {
      throw new Error('La date de fin doit être postérieure à la date de début');
    }
  }

  overlaps(other: BookingPeriod): boolean {
    return this.startDate < other.endDate && other.startDate < this.endDate;
  }
}

// Entity (Aggregate Root)
class Booking {
  private status: 'pending' | 'confirmed' | 'cancelled';
  
  constructor(
    public readonly id: BookingId,
    public readonly resourceId: ResourceId,
    private period: BookingPeriod,
    public readonly customerId: CustomerId
  ) {
    this.status = 'pending';
  }

  // Méthode métier utilisant l'Ubiquitous Language
  confirm(): void {
    if (this.status !== 'pending') {
      throw new Error('Seules les réservations en attente peuvent être confirmées');
    }
    this.status = 'confirmed';
    // Émettre un événement domain: BookingConfirmed
  }

  cancel(reason: CancellationReason): void {
    if (this.status === 'cancelled') {
      throw new Error('La réservation est déjà annulée');
    }
    this.status = 'cancelled';
    // Émettre un événement domain: BookingCancelled
  }
}

// Repository Interface
interface BookingRepository {
  save(booking: Booking): Promise<void>;
  findById(id: BookingId): Promise<Booking | null>;
  findOverlapping(resourceId: ResourceId, period: BookingPeriod): Promise<Booking[]>;
}

Mise en œuvre du DDD

1. Event Storming : ateliers collaboratifs pour identifier événements métier, commandes et aggregates
2. Définition du langage ubiquitaire : création d'un glossaire métier partagé et maintenu activement
3. Identification des Bounded Contexts : cartographie des sous-domaines et de leurs frontières
4. Modélisation tactique : implémentation des patterns (Entities, Value Objects, Aggregates, Domain Services)
5. Architecture hexagonale : isolation du domaine des préoccupations techniques (infrastructure, API)
6. Tests orientés métier : validation des règles métier via des tests expressifs et lisibles
7. Itération continue : affinement du modèle au fil des découvertes et évolutions métier

Outils et frameworks DDD

• NestJS avec CQRS : framework Node.js offrant des abstractions pour Event Sourcing et CQRS
• Axon Framework : plateforme Java facilitant l'implémentation de DDD et Event Sourcing
• EventStorming : méthodologie collaborative pour découvrir et modéliser le domaine
• Context Mapper : outil de modélisation visuelle des Bounded Contexts et leurs relations
• Domain Storytelling : technique narrative pour capturer les processus métier

Le Domain Driven Design représente bien plus qu'un ensemble de patterns techniques : c'est une philosophie plaçant la compréhension profonde du métier au centre du processus de développement. En adoptant le DDD, les organisations réduisent significativement les coûts de maintenance, accélèrent la mise en production de nouvelles fonctionnalités et créent des systèmes véritablement alignés sur leurs objectifs stratégiques. Cette approche est particulièrement pertinente pour les domaines métier complexes où la collaboration entre experts métier et techniques devient un avantage compétitif décisif.