Pourquoi les modèles de domaine importent davantage à l'ère de l'IA

L'architecture logicielle est souvent un débat sans vainqueur. Vous construisez un système. Vous ne construisez jamais l'alternative dans les mêmes conditions. Cela rend chaque décision infalsifiable. Lorsqu'un système échoue, on blâme le domaine ou l'équipe. On blâme rarement l'architecture car il n'y a pas de groupe de contrôle pour la comparer.

Nous avons besoin d'un moyen de tester nos conceptions. Nous devons séparer la complexité essentielle de la complexité accidentelle. La complexité essentielle est le problème réel. La complexité accidentelle est le désordre que nous créons avec nos outils et nos processus.

L'IA rend l'implémentation presque gratuite. C'est un changement massif. Par le passé, la friction liée à l'écriture du code forçait les développeurs à créer de meilleures structures. Si votre code était un désordre, il devenait difficile à gérer. Cette douleur servait de boucle de rétroaction.

L'IA élimine cette friction. Elle peut écrire du code désordonné et mal structuré aussi rapidement que du code propre. La douleur d'un mauvais modèle ne frappe plus le développeur pendant le build. Au lieu de cela, la douleur se déplace vers la production. Vous vous retrouvez avec des données corrompues et des tâches d'intégration impossibles.

Un modèle de domaine riche est un outil pour prévenir cela. Il remplit trois fonctions spécifiques :

  • Il vous aide à apprendre le domaine en vous obligeant à donner une forme aux concepts.
  • Il définit le domaine de sorte que le « quoi construire » ne soit plus une supposition.
  • Il documente le domaine dans un code qui reste à jour grâce au compilateur.

Pour être efficace, un modèle de domaine doit suivre trois règles :

  • Préservez l'intégrité de la complexité essentielle. Ne dispersez pas un concept unique à travers des centaines de microservices.
  • Fournissez un retour (feedback). Une hypothèse erronée devrait provoquer une erreur de compilation, et non un bug silencieux.
  • Gardez les changements peu coûteux. Vous devriez pouvoir corriger un concept à un seul endroit, plutôt que de devoir le traquer dans dix services.

Si vous divisez votre domaine trop tôt en microservices pour résoudre le problème de la « lourdeur », vous ne faites souvent que déplacer le désordre. Vous échangez un unique « god object » contre un désordre distribué plus difficile à suivre. Une dépendance que vous ne pouvez pas voir est une dépendance qui cassera en production.

L'objectif d'un modèle de domaine riche n'est pas d'avoir raison. L'objectif est de rendre l'erreur visible tant que le coût de correction est encore faible.

Source: https://dev.to/leonpennings/what-is-the-reason-for-using-a-rich-domain-model-in-the-age-of-ai-3gg

Optional learning community: https://t.me/GyaanSetuAi