Refactoring dans la conception orientée domaine [fermé]

Je viens de commencer à travailler sur un projet et nous utilisons la conception pilotée par domaine (telle que définie par Eric Evans dans Domain-Driven Design: Tackling Complexity in the Heart of Software . Je crois que notre projet est certainement un candidat pour cette conception modèle comme Evans le décrit dans son livre.

Je me bats avec l'idée de refactoriser constamment.

Je sais que le refactoring est une nécessité dans tout projet et se produira inévitablement à mesure que le logiciel change. Cependant, d'après mon expérience, le refactoring se produit lorsque les besoins de l'équipe de développement changent, et non pas comme la compréhension du domaine change ("refactoring pour une meilleure compréhension" comme l'appelle Evans). Je m'intéresse surtout aux percées dans la compréhension du modèle de domaine. Je comprends que je fais de petits changements, mais que se passe-t-il si un grand changement dans le modèle est nécessaire?

Quel est un moyen efficace de vous convaincre (et convaincre les autres) que vous devriez refactoriser une fois que vous avez obtenu un modèle de domaine plus clair? Après tout, la refactorisation pour améliorer l'organisation ou les performances du code pourrait être complètement distincte de la façon dont l'expression est expressive en termes de code de langage omniprésent. Parfois, il semble juste qu'il n'y ait pas assez de temps pour refactoriser.

Heureusement, SCRUM se prête au refactoring. La nature itérative de SCRUM permet de construire facilement une petite pièce et de la changer. Mais au fil du temps, cette pièce deviendra plus grande et que se passe-t-il si vous avez une percée après que cette pièce soit si grande qu'elle sera trop difficile à changer?

Quelqu'un a-t-il travaillé sur un projet utilisant une conception orientée domaine? Si c'est le cas, ce serait formidable d'avoir un aperçu de celui-ci. Je voudrais surtout entendre des histoires de réussite, car DDD semble très difficile à bien faire.

Merci!

Je suis un grand fan de DDD depuis un certain temps (avec et sans le filet de sécurité d'un framework de test).

L'ensemble du concept et du cycle de vie du refactoring ne change pas car vous utilisez maintenant une nouvelle méthodologie de conception. Si cela prend beaucoup de temps, il doit avoir un avantage proportionnel au projet pour obtenir ce temps de la direction.

En ce qui concerne le faire: dans un cas, j'ai participé à une refactorisation majeure de 3 mois en raison d'une «percée» dans la compréhension du modèle de domaine. Il a fallu des tests pour vérifier le comportement actuel, des tests pour vérifier le comportement attendu et des modifications du code appelant. Cependant, les avantages ont été importants et ont permis à l'entreprise de faire beaucoup plus de choses qu'elle devait faire auparavant, mais qu'elle n'était tout simplement pas en mesure de le faire. En substance, le refactoring était essentiellement une «fonctionnalité».

La refactorisation dans la conception pilotée par domaine est, je pense, motivée par un besoin, et non par un «gentil» refactor. Dès que vous identifiez un modèle de domaine incorrect, le code / système ne représente pas le problème réel.

Par exemple, nous avons récemment travaillé sur une application d'une complexité de domaine raisonnable. C'était un système de facturation / contrat, et nous introduisions un nouveau type de taux. Nous utilisions un processus agile, des mêlées de 2 semaines pour être précis.

Initialement, nous avons identifié dans le modèle que les 2 taux étaient complètement séparés et n'avaient aucune relation, sauf par le biais du contrat. Cependant, alors que nous terminions plus d'histoires, nous nous sommes rendu compte qu'elles étaient en fait les mêmes, surtout lorsque nous avons commencé à envelopper le nouveau taux comme un ancien juste pour le faire fonctionner. Ce fut le premier signe d'avertissement.

Pour résumer l'histoire, nous avons pu obtenir 90% des histoires avec le modèle incorrect, mais nous sommes arrivés au point où, dans chaque partie du code, nous enveloppions le nouveau taux comme un ancien, et / ou création si newRate else oldRate EVERY où. Nous nous cognions la tête contre le mur de briques proverbial. Nous étions à mi-chemin de cette partie du projet et savions que le temps à compléter sera exponentiel ou irréalisable avec le modèle de domaine incorrect. Nous avons donc mordu la balle, divisé une histoire en huit autres histoires et refactorisé le modèle de domaine.

Lorsque nous avons terminé le projet, nous savions avec le recul que c'était la bonne chose à faire et que c'était la SEULE chose à faire pour le faire correctement.

Cela a-t-il pris du temps? Oui, mais si nous ne l'avions pas fait, cela aurait pris plus de temps. Est-ce que DDD a été bien fait? Eh bien, curieusement, nous ne connaissions pas DDD à l'époque, mais peu de temps après, nous avons assisté à un atelier DDD par Eric Evans, et tout ce que mes collègues et moi-même pouvions faire était de hocher la tête. Je pense que si nous connaissions DDD, nous aurions récupéré le refactor beaucoup plus tôt, économisant ainsi plus de temps.

Si vous rencontrez un problème dans le modèle de domaine, il est important de le corriger. D'après mon expérience, nous avons manqué un peu dans la façon dont le modèle de domaine se connecte à ses différentes entités lorsque nous en avons implémenté une partie.

Cela a abouti à ce que les gens modélisaient de façon inattendue et cassent ainsi d'autres parties du modèle pour essayer de "le faire fonctionner".

Dès que vous réalisez qu'il y a quelque chose de mal dans le modèle de domaine, changez-le le plus rapidement possible. Plus il faudra de temps pour le refactoriser, plus il sera difficile de changer par rapport aux utilisateurs, dont les modèles mentaux sont désormais adaptés.

Pour certaines parties du code, le refactoring continu est exagéré. Pour une autre partie du code (en DDD, le soi - disant base de domaine ) est une nécessité. Comprendre que le code n'est pas ce qu'il devrait être impose une charge cognitive supplémentaire au développeur (la différence entre notre compréhension du domaine et l'implémentation actuelle) qui rendra les évolutions plus difficiles et / ou coûteuses.

La question est: "ces évolutions seront-elles nécessaires?". Dans le domaine principal (le domaine qui fait la différence), la réponse est "Oui!". Parce que c'est la potion du domaine qui préoccupe le plus l'entreprise et celle qui fera la différence pour les parties prenantes. C'est l'endroit où vous voulez garder votre code en parfait état, prêt à implémenter la prochaine exigence avec un minimum d'effort, en raison de la flexibilité de votre modèle de domaine.

Cependant qui va être coûteux lorsqu'il est appliqué à tous le code d'application. Les domaines qui ne sont pas si importants pour l'entreprise (sous - domaines de support ou génériques dans le jargon DDD) peuvent nécessiter une approche moins sophistiquée que celle réservée au noyau.