DDD - Simplifiez votre code, sécurisez votre IT

Pourquoi cette approche devient utile quand le métier se complique

Je vois cette approche payer surtout quand le logiciel est traversé par des règles métier nombreuses, des exceptions et des compromis. Si le vocabulaire change selon les équipes, si les règles sont dans les contrôleurs, les vues et les procédures SQL, ou si deux parties du produit donnent un sens différent au même mot, le modèle n’exprime plus la réalité du métier. Dans ces cas-là, il devient plus rentable de modeler le domaine que d’ajouter encore une couche technique.

Concrètement, cela se voit dans les secteurs où la logique est dense: assurance, banque, santé, logistique, marché public, cybersécurité managée ou plateformes B2B. Le point commun n’est pas la taille de l’entreprise, mais la complexité des règles et la fréquence des évolutions. C’est cette pression qui justifie une modélisation plus rigoureuse, pas le simple goût des architectures élégantes.

Autrement dit, on ne cherche pas à faire du DDD pour le principe; on cherche à réduire l’ambiguïté, à limiter les effets de bord et à rendre les changements métier plus sûrs. Pour cela, il faut clarifier quelques concepts, sinon on finit vite avec un vernis méthodologique sans bénéfice réel.

Les concepts à maîtriser pour ne pas réduire le sujet à des diagrammes

Le piège classique, c’est de transformer une approche de modélisation en collection de mots techniques. En pratique, je conseille de retenir quatre idées simples avant tout le reste. Elles structurent le code, mais surtout la conversation avec le métier.

Le langage ubiquitaire

C’est le vocabulaire partagé par les métiers, les développeurs, le produit et, idéalement, les équipes sécurité et exploitation. Le but n’est pas de simplifier à l’extrême, mais de rendre les termes non ambigus: un client, un compte, une autorisation ou un incident doivent avoir une définition stable. Si le mot ne veut pas la même chose pour tout le monde, le code finit par mentir.

Les contextes bornés

Un contexte borné délimite la zone dans laquelle un modèle a un sens précis. Le même terme peut exister dans plusieurs contextes, mais avec des règles différentes. C’est une idée très utile dans les organisations réelles, parce qu’elle accepte la diversité des besoins au lieu d’imposer un faux modèle unique qui écrase tout. En pratique, cela évite de faire cohabiter des règles incompatibles dans le même espace de décision.

Entités, objets-valeurs et agrégats

Une entité est définie par son identité dans le temps, alors qu’un objet-valeur est défini par ses attributs. Un agrégat, lui, regroupe des objets qui doivent être cohérents ensemble. Je m’en sers pour protéger les invariants métier, c’est-à-dire les règles qui ne doivent jamais être violées, comme un montant négatif interdit, une validation impossible ou une transition d’état illégale. Bien utilisés, ces concepts rendent le code plus lisible et les erreurs plus difficiles à introduire.

Lire aussi : Blockchain en cybersécurité - Vrai potentiel ou simple buzz ?

Les événements de domaine

Un événement de domaine décrit quelque chose d’important qui vient de se produire dans le métier: une commande validée, un accès refusé, un contrat signé, une alerte levée. Ils sont utiles pour découpler les réactions, tracer les changements et faire circuler l’information entre contextes sans créer de dépendances trop serrées. Attention toutefois: un événement métier n’est pas un simple log technique. Il doit raconter quelque chose de pertinent pour le modèle.

Une fois ces notions clarifiées, on peut passer à la mise en œuvre. C’est là que les projets réussissent ou se perdent dans la surarchitecture.

Comment je la mets en place sans surarchitecture

Je ne commence jamais par les microservices, ni par les frameworks. Je commence par le flux métier le plus douloureux, puis je travaille en petits incréments. L’objectif n’est pas de dessiner un système parfait, mais de faire émerger un modèle utile, compréhensible et assez robuste pour survivre aux prochains changements.

1. Je choisis un sous-domaine critique, celui où les erreurs coûtent cher ou reviennent souvent.
2. Je réunis les bonnes personnes pendant 2 à 3 heures: métier, produit, architecture, sécurité et exploitation si le sujet l’exige.
3. Je fais émerger le vocabulaire réel, y compris les mots flous, les exceptions et les cas limites.
4. Je découpe ensuite 1 à 3 contextes bornés, pas davantage au départ.
5. Je traduis ce cadrage dans un premier incrément fonctionnel, puis je valide le modèle avec des tests de comportement.

Je privilégie un premier périmètre réduit, parfois une seule équipe et un seul processus métier, parce que la qualité du modèle se voit dans les arbitrages, pas dans le nombre de diagrammes. Le bon signal, c’est une baisse des ambiguïtés et des corrections en chaîne, pas une explosion de concepts sophistiqués.

Ce que cela change pour la cybersécurité et la conformité

Dans un contexte sécurité, cette approche est intéressante parce qu’elle clarifie où se trouvent les responsabilités, les données sensibles et les zones de confiance. Je m’en sers souvent comme aide à la décision pour distinguer ce qui relève du métier, ce qui relève de l’accès, et ce qui doit être isolé. Le gain n’est pas seulement architectural: il devient aussi opérationnel.

• Réduction du périmètre d’exposition. Quand les contextes sont bien séparés, il est plus simple de limiter la propagation d’une erreur ou d’un accès non autorisé.
• Frontières de confiance plus lisibles. On distingue mieux ce qui peut circuler librement de ce qui doit rester sous contrôle fort.
• Traçabilité métier plus utile. Les événements de domaine facilitent les audits fonctionnels, à condition de les penser comme des faits métier et non comme des journaux techniques.
• Moins d’ambiguïté sur les données sensibles. Le modèle aide à poser des questions concrètes sur la classification, la conservation, l’accès et la minimisation.

Mais il faut rester net sur une chose: un modèle bien découpé n’est ni un contrôle d’accès, ni une politique de chiffrement, ni un audit. Il aide à structurer la réponse sécurité, mais il ne la remplace pas. Dans un projet sérieux, je le combine toujours avec le cloisonnement des permissions, la classification des données, la journalisation et le threat modeling.

Cette valeur dépend toutefois du niveau de complexité du produit. Pour savoir si l’effort vaut la peine, il faut comparer avec une approche plus légère.

Quand l’utiliser et quand choisir une solution plus légère

Le critère décisif, pour moi, est simple: si les règles sont stables et que le métier ne fait que manipuler des formulaires, une architecture plus légère sera plus rapide et plus sûre à maintenir. Si, en revanche, les règles sont nombreuses, interconnectées et exposées à des changements fréquents, le surcroît de modélisation paie souvent dès les premiers mois.

Une fois ce choix posé, il reste à éviter les erreurs qui font perdre tout le bénéfice de la démarche.

Les erreurs qui coûtent le plus cher

Je retrouve presque toujours les mêmes dérives quand un projet déclare vouloir modéliser le domaine sans en assumer les contraintes réelles. Elles sont faciles à repérer, mais elles coûtent cher parce qu’elles donnent l’illusion d’une bonne architecture alors que la complexité reste mal gérée.

• Partir des classes au lieu du métier. Le code reproduit alors des objets techniques au lieu de refléter les règles réelles.
• Confondre contexte borné et microservice. Les frontières métier ne coïncident pas toujours avec les frontières de déploiement, et les mélanger trop tôt crée des rigidités inutiles.
• Transformer chaque objet en concept sophistiqué. Tout n’a pas besoin d’un agrégat, d’un événement ou d’un service de domaine; l’excès de structure brouille le modèle.
• Ignorer l’évolution du langage. Un vocabulaire figé devient vite faux si le métier change ou si l’équipe découvre de nouveaux cas.
• Déplacer la complexité au lieu de la réduire. Le pire scénario consiste à rendre le système plus difficile à lire sans améliorer la compréhension du domaine.

Le piège le plus fréquent est presque toujours le même: on multiplie les concepts pour donner l’impression de maîtriser la complexité, alors qu’on l’a seulement déplacée. Ce que je surveille, c’est la lisibilité des décisions, la stabilité des termes et la capacité de l’équipe à expliquer le modèle à un nouveau venu en quelques minutes.

Quand ces trois critères se dégradent, le modèle devient un obstacle plus qu’un levier, ce qui appelle un dernier arbitrage avant de généraliser.

Les arbitrages que je valide avant de généraliser cette approche

Si je dois résumer ma façon de procéder, je garde trois questions en tête: le domaine mérite-t-il vraiment un modèle riche, le périmètre choisi est-il assez petit pour apprendre vite, et l’équipe a-t-elle les moyens de maintenir le vocabulaire et les frontières dans la durée?

• Commencer par un sous-domaine critique, pas par tout le système.
• Documenter le vocabulaire métier dans un format simple et vivant.
• Mesurer le succès à la baisse des ambiguïtés, des incidents fonctionnels et des retours arrière.
• Revoir les frontières après le premier incrément réel, pas seulement sur le papier.

Je garde aussi une règle très pragmatique: si le modèle n’aide pas le métier à mieux se reconnaître dans le logiciel, il faut le simplifier. Bien appliquée, cette approche ne produit pas seulement une architecture plus propre; elle rend surtout les décisions plus sûres, ce qui est exactement ce qu’on attend d’un système critique en informatique et en cybersécurité.