Implémenter le Domain-Driven Design dès le départ
mercredi 20 novembre 2013 à 09:46 nabella, le 20/11/2013 à 09:46
Ce concept de DDD me laisse dubitatif ... Je n'ai pas vraiment creusé le truc, mais présenté comme ça, cela me paraît être un danger pour les architectures logicielles.
En effet, à faire des développements centrés sur le métier, on risque de rapidement perdre toutes les possibilités de réutilisation de code pour d'autres métiers. Poussé à l'extrême, ça va jusqu'à rendre le nom des variables ou des méthodes incompréhensible pour les développeurs. Comment comprendre que, selon le métier, ce qu'on appel une "règle" dans un métier peut être une "règle de règle" dans un autre métier, un "filtre" dans un troisième ...
Je ne dis pas que l'approche est mauvaise. Peut-être est-elle pertinente chez des éditeurs logiciel spécialisés sur un métier donné (mais c'est une stratégie qui me parait dangereuse). Peut-être est-elle pertinente si on fait un effort particulier pour créer des couches d'abstraction supplémentaires entre le cœur métier et les implémentations technique (mais ça me parait être fort couteux).
Mais quoi qu'il en soit, je pense qu'une approche générique reste plus efficace. Avec une couche d'abstraction pour passer au métier. C'est aussi assez couteux, car ça demande une vrai recherche côté architecture (faire simple, c'est compliqué ;)), mais à long terme, c'est ce qui me semble être le plus rentable : le jour où le métier décline, on peut switcher sur un autre sujet sans problème.
(Permalink)
Ce concept de DDD me laisse dubitatif ... Je n'ai pas vraiment creusé le truc, mais présenté comme ça, cela me paraît être un danger pour les architectures logicielles.
En effet, à faire des développements centrés sur le métier, on risque de rapidement perdre toutes les possibilités de réutilisation de code pour d'autres métiers. Poussé à l'extrême, ça va jusqu'à rendre le nom des variables ou des méthodes incompréhensible pour les développeurs. Comment comprendre que, selon le métier, ce qu'on appel une "règle" dans un métier peut être une "règle de règle" dans un autre métier, un "filtre" dans un troisième ...
Je ne dis pas que l'approche est mauvaise. Peut-être est-elle pertinente chez des éditeurs logiciel spécialisés sur un métier donné (mais c'est une stratégie qui me parait dangereuse). Peut-être est-elle pertinente si on fait un effort particulier pour créer des couches d'abstraction supplémentaires entre le cœur métier et les implémentations technique (mais ça me parait être fort couteux).
Mais quoi qu'il en soit, je pense qu'une approche générique reste plus efficace. Avec une couche d'abstraction pour passer au métier. C'est aussi assez couteux, car ça demande une vrai recherche côté architecture (faire simple, c'est compliqué ;)), mais à long terme, c'est ce qui me semble être le plus rentable : le jour où le métier décline, on peut switcher sur un autre sujet sans problème.
(Permalink)