Réponse courte… parce que le modèle est souvent lié à la génération de code et que le code est fragile; ce dont nous avons besoin, c'est de l'élimination du code et du modèle est certainement la voie à suivre.
Certains ont rejeté la question en faisant valoir qu'il n'y a pas de marteau d'or et que le développement de logiciels est intrinsèquement complexe.
Je suis tout à fait d'accord avec eux qu'il n'y a pas de marteau en or mais je ne pense pas que le modèle piloté soit une quête de marteaux en or ou de balles en argent!
Je voudrais aller plus loin dans la complexité; il y a deux sortes de complexité, que j'appelle la complexité organique ou naturelle, complexité inhérente à l'entreprise et à ses processus, mais nous avons aussi la complexité cérémonielle.
Une complexité qui s'introduit jour après jour dans le système, instruction par instruction. La complexité cérémonielle - complexité inutile - émerge essentiellement de la manipulation incontrôlée du code technique avec le code orienté métier, mais aussi du manque de structure et d'uniformité du système.
Aujourd'hui, toute la complexité qui hante le développement des systèmes d'information et provoque l'échec et la taille est une complexité cérémonielle; complexité qui peut être éliminée.
La complexité cérémonielle est un gaspillage, un gaspillage causé par un code, une valeur moindre, un changement défavorable, un code invariant; code qui doit être réduit à son strict minimum.
Comment faire ça? Facile, il suffit de ne pas l'écrire et de ne pas le générer, en premier lieu!
Code technique nécessaire et invariant; code utilisé pour lire / écrire, afficher, communiquer… Les données.
C'est comme un système d'exploitation, vous ne le réécrivez pas pour chaque projet que vous utilisez. Donc, ce qu'il faut, c'est un moteur technique qui gère les aspects invariants du logiciel étant donné un modèle. Je l'appelle un moteur AaaS (Architecture as a Service).
En ce qui concerne le code inutile, il s'agit bien d'un code inutile, il est donc préférable de le laisser non écrit.
Cela nous laisse avec le code nécessaire, orienté métier qui devrait être écrit, les données orientées métier nécessaires qui devraient être conçues et l'interface utilisateur et l'expérience nécessaires qui devraient être conçues et imaginées.
En éliminant le code fragile, nous pouvons adopter l'architecture en tant que service, un nouveau paradigme pour le développement logiciel basé beaucoup plus sur la modélisation et la conception que sur le code.