Dans son excellent livre "Requirements & Spécifications", dont je vous promets de parler bientôt, Michaël Jackson nous offre un conseil qui vaut de l'or :
💡Ne suivez pas les conseils des enthousiastes d'une méthode. Les meilleurs viennent de ceux qui soignent le problème plus que leur solution [1]
Le fait est qu'une méthode (p. ex. DDD) n'est jamais qu'une méthode. Et qu'elle s'applique plus ou moins bien à un problème donné. Jackson théorise cela magnifiquement avec son Problem Frame.
Du reste, les méthodes il faut les connaître pour les utiliser à bon escient ou encadrer leur usage (c'est mon job). Il faut surtout en connaître plusieurs. Et en trier les contributions, le bon grain et l'ivraie.
Ma critique de DDD/Hexa est opportuniste, certes. Je ne m'en estime pas expert, et je ne m'en cache pas.
Mais j'en ai étudié bien d'autres (OMT, UML, Z, Event B, Abstract State Machines, JSP/Problem Frames, KAOS, TTM/RM, Agile/XP/Scrum, UX Design, Clean Code, et j'en passe [2]).
Chaque étude passe par une exploration des frontières, des risques et opportunités.
Et ça peut passer par dire des conneries, d'utiliser à bon escient l'accroche de LinkedIn pour faire remonter à moi les experts fragiles et ceux qui savent trier aussi, et m'expliquer les tradeoffs.
Merci à eux.
Car ces experts je les engage aussi parfois (c'est mon job).
Je suis un troll machiavélique, j'avoue. C'est dans l'intérêt de mes propres clients, je m'intéresse à leurs problèmes.
#SoftwareEngineering