J'ai entendu parler du développement piloté par domaine d'un développeur de la région. Il en a parlé comme s'il s'agissait de la solution miracle aux exigences changeantes.
J'ai lu le wiki . Toujours pas trop clair. Qu'est-ce que la «3D» en termes pratiques? Est-il vraiment étonnant que maintenant la création de diagrammes de classes UML soit juste obsolète?
Réponses:
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.
Une description de haut niveau pourrait être -
Modélisez vos classes pour refléter les structures de données et le comportement de votre domaine problématique.
Cela vous permet de mapper les modifications de votre domaine problématique directement avec les modifications de votre code, il devrait donc être plus facile de mettre à jour à mesure que votre domaine problématique évolue.
AVERTISSEMENT: j'ai ajouté cette réponse après que cette question a été marquée comme doublon. Je ne suis pas d'accord, mais nous y voilà. :-)
La conception pilotée par domaine vise à concevoir des logiciels dans des domaines de haute valeur / haute complexité.
Cela se transforme en une approche différente pour la création de logiciels d'entreprise: il y a trop d'apprentissage impliqué, et la conséquence la plus importante est que vous n'obtiendrez pas la bonne solution au premier coup.
Ou la combinaison des deux.
Dans les deux cas, vous aurez besoin de bonnes bases logicielles pour réécrire fréquemment des logiciels. C'est la raison pour laquelle le livre a insisté sur un ensemble donné de modèles autour du modèle de modèle de domaine: ils étaient la combinaison la plus raisonnable en 2004.
Cependant, la POO et le schéma tactique ne sont pas la chose la plus importante. La maîtrise technique est nécessaire pour construire de grands logiciels de manière évolutive. Mais ce n'est qu'un ingrédient de la recette. Les autres?