Les développeurs confondent souvent modélisation et design applicatif. Les deux sont proches, mais n’adressent pas le même objectif.

Le Model-Driven Design (Domain-Driven Design) est dédié à la modélisation de sujets complexes. Il repose sur deux concepts :

1. Une approche pour modéliser un problème complexe : Deep Model.
2. Une démarche pour obtenir un design propre : Supple Design.

Prenons un exemple : vous être face à une règle de métier complexe. Votre cerveau est en ébullition. Vous ne savez pas comment l’implémenter cette nouvelle règle qui comprend plusieurs axes fonctionnels. Pas de stress : notre cerveau fonctionne rapidement sur ce qu’il a déjà rencontré et beaucoup plus lentement sur des sujets inexplorés. Les techniques permettant de creuser les problèmes complexes (Event Storming, Story Mapping, Example Mapping …) nous permettent de nous acclimater sur des sujets dont nous ne sommes pas spécialistes. L’émergence de nouveaux modèles mentaux nous apporte un début de compréhension, mais rarement la solution. J’aime rappeler ici que ce travail de compréhension est sublimé lorsqu’il est collaboratif. Nos échanges autour d’un point de désaccord nous permettent de partager et d’aligner nos modèles mentaux de manière explicite. C’est donc à travers une compréhension commune et un vocable commun que commence une bonne modélisation.

Sur le plan de l’implémentation, la modélisation relève d’une approche à la fois frugale et progressive :

• Frugale: car tout élément ne contribuant pas directement au modèle sera éliminé. C’est un acte difficile, car nous aimons bien ce que nous connaissons bien.
• Progressive: car nos modèles mentaux évoluent au fil des obstacles rencontrés. C’est une forme de Refactoring conduit vers une meilleure compréhension du problème. C’est à la fois chronophage et impraticable, lorsque la pression du backlog vous oblige à agir de plus en plus vite.

 Modéliser est donc un acte d’analyse au service d’un problème fonctionnel. Mais, ce travail d’analyse peut être amélioré si nous apportons des éléments de design permettant de clarifier notre modèle. En d’autres mots, le design apporte au modèle une expressivité permettant de retrouver l’intention des experts métier. C’est donc en conjuguant la modélisation et le design que nous pouvons atteindre une solution opérationnelle offrant un superbe design et une modélisation parfaitement juste.

Je vous encourage à vous exprimer lorsque vous êtes engagé sur une règle de métier complexe afin de disposer d’un temps suffisant pour l’explorer et l’implémenter. Si vous escamotez systématiquement ces moments de compréhension et de Refactoring progressif, vous obtiendrez un code difficile à la fois difficile à comprendre et peu évolutif. En d’autres mots, en réduisant le temps d’analyse et le temps d’implémentation, nous augmentons le temps de maintenance et les actions correctifs après la livraison du produit.

Une fois que  l’application est livrée, corriger un souci de modélisation est à la fois difficile et plus chronophage au regard du temps nécessaire pour développer un code souple et expressif. En négligeant,  la phase de modélisation et son design respectif, les projets informatiques sont systématiquement coûteux et génère une énorme dette technique au fil du temps.