Eh bien, tout d'abord, je ne pense pas que l'article Wikipédia auquel vous faites référence soit très bon, principalement parce qu'il fait référence à un tas de choses qui ne sont qu'accessoires à la conception pilotée par domaine et ne fait pas grand-chose pour éclairer quiconque sur la pratique.
Mais, en tant que personne qui a pris à cœur la conception pilotée par domaine (qui utilise généralement DDD, plutôt que 3D, pour ce que cela vaut), j'ai toujours senti que les principes fondamentaux de DDD sont évidents, si vous lisez autant que le premier chapitre d'Eric. Le livre d'Evans. Mais c'est un ensemble de modèles et de pratiques, il n'est donc pas si facile de résumer en 3 phrases ce que c'est et quels sont les avantages sans entrer dans les détails. Les détails qui résonnent avec une seule personne peuvent également être très différents; il est probable qu'il y a 10 ans, je ne l'aurais pas du tout vu moi-même.
DDD n'est pas une solution miracle. Lorsque cela est fait de manière raisonnable, il s'agit d'adopter une approche artisanale pour la création de logiciels et de reconnaître la nécessité de réduire la friction cognitive entre les équipes de développement et les entreprises pour lesquelles elles créent des logiciels. L'une des pratiques les plus importantes consiste à disposer d'une couche dans laquelle le vocabulaire de domaine utilisé par l'équipe logicielle et l'équipe commerciale correspond le plus possible. Vous créez cette couche de manière itérative à mesure que vous comprenez le problème commercial que vous essayez de résoudre. Lorsque la logique métier est sensiblement codée dans cette couche, isolée de toutes les dépendances alambiquées que les applications d'entreprise ont généralement en factorisant les interactions avec ces systèmes vers les interfaces, le langage utilisé dans la couche de domaine réelle devient finalement assez concis, évident et lisible.
Compte tenu de la forme dans laquelle j'ai vu la plupart des logiciels d'entreprise, dans la pratique, DDD peut sembler une solution miracle, car la plupart des logiciels d'entreprise ont une séparation des préoccupations si médiocre qu'il est presque impossible à tester, et l'équipe logicielle vit dans une grande peur du changement car ils ne savent pas quels pourraient être les effets secondaires de changements de code apparemment même triviaux, alors qu'une couche de domaine correctement factorisée sera indépendamment testable et vérifiable. Mais en réalité, DDD reconnaît que les systèmes existent rarement de manière isolée. DDD comprend des modèles d'adaptation pour les systèmes hérités (couche anti-corruption, contextes délimités, pour n'en nommer que quelques-uns).
Si vous pratiquez la conception orientée objet, y compris la discipline du couplage lâche, et que vous pratiquez les tests unitaires de manière assez religieuse, et que vous refactorisez sans pitié le code, et que vous travaillez avec des experts du domaine lors de la construction de votre système, vous obtiendrez essentiellement un résultat qui est essentiellement ce dont parlent les défenseurs de la conception pilotée par domaine.
Il y a quelques modèles spécifiques décrits dans le livre d'Evans qui s'appliquent principalement au développement de logiciels d'entreprise, et certains qui sont des principes assez universels, mais essentiellement, DDD est une approche pragmatique du développement de logiciels qui peut, au fil du temps, réduire l'accumulation de dette technique, et rendre vos clients plus heureux parce que vous êtes en mesure de parler la même langue et de proposer des solutions plus efficaces grâce aux avantages d'une meilleure compréhension mutuelle.
