Principes du Domain-Driven Design (DDD) appliqués au développement d’un système ERP
Un ERP (Enterprise Resource Planning) agrège de nombreux domaines métier—achats, ventes, stock, production, finance, conformité—avec des règles complexes et des évolutions constantes. Le Domain-Driven Design (DDD) aide à structurer le logiciel autour de la logique métier réelle, plutôt que d’organiser le code selon des couches techniques. Les principes DDD favorisent ainsi une meilleure maintenabilité, une réduction des ambiguïtés et une capacité accrue à absorber le changement.
Comprendre le contexte : Bounding Context et langage partagé
Le cœur du DDD consiste à relier étroitement le code au langage métier. Les notions, termes et règles doivent être clarifiés grâce à un langage omniprésent (ubiquitous language) utilisé par les équipes métier et techniques.
Bounding Context : éviter les modèles incohérents
Dans un ERP, le terme “commande” peut recouvrir des réalités différentes selon le contexte : une commande client en vente, une commande fournisseur en achats, ou encore une demande en production. Le Bounding Context permet de définir des modèles distincts, chacun adapté à son domaine.
Une cartographie simple peut être établie :
- Sales : commandes clients, livraison, facturation associée
- Procurement : commandes fournisseurs, réceptions, conformité
- Inventory : mouvements de stock, réservations, valorisation
- Finance : écritures comptables, taxes, rapprochements
- Production : ordres de fabrication, nomenclatures, capacités
Exemple de langage omniprésent
Un modèle unifié doit garantir que les règles sont exprimées avec cohérence. Par exemple :
CommandeClient → statut & lignes & remises
CommandeFournisseur → statut & conditions & réceptions
Définir le modèle de domaine : Entités, Valeurs et Aggrégats
Le DDD propose une manière de représenter les concepts métier. Les règles de cohérence doivent être protégées au bon niveau, généralement via des agrégats.
Entités et objets valeur
Un ERP contient des objets durables et identifiables (ex. une commande), ainsi que des objets descriptifs (ex. une adresse, un prix, un pourcentage).
- Entités : possèdent un identifiant stable (ex. CommandeClient)
- Objets valeur : immuables, sans identité propre (ex. Montant, Adresse)
Aggrégats : cohérence transactionnelle et invariants
La notion d’agrégat délimite un ensemble d’objets dont les invariants doivent rester cohérents. Le verrouillage conceptuel se fait via une racine d’agrégat qui expose un comportement garantissant les règles.
Exemple simplifié d’agrégat “CommandeClient”
class CommandeClient {
private CommandeId id;
private List<LigneCommande> lignes;
private StatutCommande statut;
public void ajouterLigne(LigneCommande ligne) {
if (statut != StatutCommande.AU_BROUILLON) {
throw new DomainRuleViolation("Ajout interdit après validation");
}
lignes.add(ligne);
}
public void valider() {
if (lignes.isEmpty()) {
throw new DomainRuleViolation("Commande vide non valide");
}
// Invariants métier : ex. validation des totaux, taxes, transport
statut = StatutCommande.VALIDEE;
}
}
Responsabilité et découpage : Services de domaine et Repositories
Le DDD sépare le comportement métier (dans le domaine) de l’infrastructure (persistance, transport, intégration). Deux éléments structurants sont souvent utilisés : Services de domaine et Repositories.
Repositories : accès au modèle, pas aux tables
Un repository représente une collection d’agrégats. Il s’agit d’une abstraction : il fournit des méthodes pour retrouver et persister les agrégats, sans exposer le schéma de base de données.
interface CommandeClientRepository {
CommandeClient findById(CommandeId id);
void save(CommandeClient commande);
}
Services de domaine : logique transversale
Les services de domaine encapsulent des opérations qui ne “tombent” pas naturellement dans une entité ou un objet valeur. Ils orchestrent des règles métier sans devenir des “god objects”.
Exemple : calcul de disponibilité en tenant compte de règles de réservation et de prévisions de production.
Événements de domaine : synchronisation métier asynchrone
Dans un ERP, de nombreuses actions déclenchent d’autres actions : validation d’une commande client → réservation stock → génération d’écritures prévisionnelles → émission de documents. Le DDD encourage l’usage d’événements de domaine pour découpler les réactions.
Quand utiliser les événements
- Quand plusieurs sous-domaines doivent réagir
- Quand une propagation synchrone rigide créerait une forte dépendance
- Quand des traitements peuvent être différés (ex. génération comptable, notifications)
Exemple : événement “CommandeClientValidée”
// Domaine
record CommandeClientValidee(CommandeId id, LocalDate dateValidation) {}
// Réaction (ex. Inventory ou Finance)
void on(CommandeClientValidee evt) {
// Réserver du stock ou préparer des écritures
}
Stratégies d’intégration : context mapping
Les interactions entre bounded contexts se gèrent via des relations décrites par le context mapping. Les patterns classiques aident à choisir une stratégie réaliste.
Intégration synchrone vs asynchrone
- Séparation stricte : les contexts échangent des événements ou des messages
- API contractuelle : synchronisation quand c’est indispensable (ex. validation de conformité)
- Anticorruption layer : protection contre la “fuite” de termes et de règles d’un context vers un autre
Pour un ERP, les frontières sont particulièrement importantes : la comptabilité suit des conventions strictes, tandis que le cycle logistique suit d’autres temporalités. Le DDD réduit les incohérences en imposant des traductions contrôlées.
Aligner l’équipe : architecture émergente et itérations
Le DDD n’est pas uniquement une technique de modélisation. Il implique une pratique : découvrir progressivement le modèle en rapprochant les équipes métier et techniques.
Approche itérative
Les premiers incréments ciblent un sous-ensemble stable du domaine (ex. gestion des commandes client), puis étendent la couverture (facturation, stock, finance). Chaque itération consolide :
- la compréhension du langage métier
- la stabilité des invariants
- la délimitation des bounded contexts
- les contrats d’intégration entre contexts
Recommandations pratiques pour un ERP
- Commencer par le domaine “pivot” : ventes ou achats, selon la valeur métier prioritaire.
- Formaliser les invariants au niveau des agrégats.
- Réduire l’ancrage technique : la logique métier doit rester dans le domaine.
- Documenter les context maps : responsables, échanges, règles de traduction.
- Exploiter les événements pour découpler les traitements lourds.
- Protéger le modèle contre la dérive : revue des termes du langage omniprésent.
Conclusion
Appliquer le Domain-Driven Design à un ERP permet de bâtir un système dont le modèle reflète réellement la complexité métier. Grâce aux bounded contexts, aux agrégats, aux invariants, aux événements de domaine et aux stratégies d’intégration, l’architecture gagne en cohérence et en capacité d’évolution. L’ERP devient ainsi un produit plus robuste, plus explicable et mieux aligné sur les besoins fonctionnels.
À propos de l'auteur
Laty Gueye Samba est développeur Full Stack basé à Dakar, Sénégal. Spécialiste des écosystèmes Java / Spring Boot et Angular.
Contact : latygueyesamba@gmail.com | Dakar, Sénégal