Est-ce que DDD est une perte de temps? [fermé]

Question

Googling "À quel type d'applications le DDD est-il adapté?" m'a donné la réponse suivante:

  

Probablement, 95% de toutes les applications logicielles relèvent du & # 8220; pas si bon pour utiliser DDD & # 8221; catégories. (voir l'article )

Alors, de quoi s'agit-il?!?

L'application sur laquelle je travaille est principalement centrée sur les données, mais contient encore une logique métier et des règles à appliquer. Serait-ce une perte de temps de commencer à appliquer les techniques DDD? Est-il préférable d'utiliser une couche d'accès aux données plus conventionnelle, un modèle de POCO et une couche de logique métier? Ou pour le dire différemment - quelle est une alternative saine au DDD?

Answer 1

De nombreux développeurs qui pensent que DDD est utile pour leur projet tombent dans le piège qui consiste à écrire du code. Ce n'est pas le cas Le travail d'un développeur consiste à réaliser des fonctionnalités afin qu'un problème puisse être résolu via un logiciel. Cela aboutit à la conclusion que l'écriture de code n'est pas le début de ce que fait un développeur, mais la fin: le code est le résultat de l'ensemble du processus AVANT que le code soit réellement écrit.

DDD n’est pas une question de rédaction de code, ce n’est pas un processus clé en main en 10 étapes pour obtenir un logiciel de qualité. / qui participe à quels flux d’informations et à quoi ressemblent ces éléments, comment ils se rapportent les uns aux autres, etc. sans interprétation erronée . C'est la "langue ubiquiste" dont parle Evans. AVANT que le code soit écrit, cela rend en fait tout un processus qui laisse peu à deviner, les choses sont claires et simples. (c'est le but).

Le problème "Comment DDD fonctionne-t-il dans la pratique" et "Quelqu'un pourrait-il me donner un exemple de la manière dont j'écris du code avec DDD?" Et ce genre de choses vient vraiment du fait que les gens qui posent ce genre de questions se concentrent sur l'écriture de code, mais n'ont aucune idée pourquoi ils écrivent ce code et pas un autre code. I.o.w .: si vous réalisez que DDD consiste à découvrir CE QUE vous devez écrire en tant que fonctionnalité et POURQUOI, les choses se mettent en place. COMMENT vous écrivez ce code, c'est vous qui décidez. Mais comme dit: ce n'est plus le plus gros problème, car vous savez déjà ce que vous devez écrire et pourquoi.

Answer 2

vous savez, parfois les 5% gagnent plus d’argent que les 95% restants - c’est la raison pour laquelle DDD existe.

il s’agit d’un grand système spécifique complexe.

Answer 3

Désolé, mais si DDD n’était qu’un moyen de penser, comme le dit Frans Bouma, il ne recommanderait pas des choses telles que Persistence Ignorance. C’est pour cela que d’autres sont considérés comme des développeurs plutôt défavorisés.

PI, pour lequel DDD a au moins un biais, est un choix architectural. Ce n'est plus une façon de penser; c'est déjà quelque chose qui vous est servi, avec la plupart du temps des avertissements trop vagues pour vous être utiles: "ne convient pas à tout".

Mais décider de suivre ou non le chemin de PI est un défi en soi, et vous ne pouvez pas appeler quelqu'un de nom ("un codeur") s'il se sent mal à l'aise.

Prenez un package ERP avec une interface semblable à celle de MS Access: grilles avec totaux cumulés, mise à jour automatique des colonnes et défilement sans pagination sur 100 000 enregistrements. Il est clair qu'une approche DDD est appropriée pour réfléchir à la manière de s'y prendre pour cette application. Mais depuis des années, je n'ai jamais vu personne - ni dans les livres ni en ligne, allant au-delà des explications étayées par des preuves, sans parler d'exemples concrets de code, de la manière dont PI pourrait gérer cette situation omniprésente pour quiconque souhaitant livrer < strong> applications de qualité commerciale et expériences utilisateur .

Je ne veux pas être religieux à ce sujet. Les partisans de DDD et de DAL ont tendance à être excessivement religieux et peuvent chasser ceux qui ont été mordus une fois mais qui sont / étaient ouverts d'esprit. Beaucoup veulent juste affronter des expériences réelles (par exemple, THINK) et ne pas être servis uniquement avec des chats, des voitures et des commandes de base (par exemple, un CODE pauvre) pour soutenir la prédication.

Answer 4

Voici une question très similaire: Autorisez-vous le niveau Web à accéder directement au DAL?

J'utilise DDD pour tous mes projets. Sur les applications plus petites, certains concepts ne s'appliquent pas, mais je trouve que de nombreux aspects s'appliquent à tous les projets, quelle que soit leur taille.

Answer 5

DDD concerne les logiciels qui seront maintenus pendant un certain temps. Pour moi, cela signifie qu'il doit exprimer des idées qui changeront avec le domaine. Bien sûr, une application simple peut être parfaite pour une livraison rapide et une mise en œuvre rapide. Cependant, si vous avez besoin de développer le logiciel, les principes de DDD vous aideront énormément. DDD est peut-être difficile au début, mais une fois que vous avez compris l’idée du langage omniprésent et des préoccupations liées à la séparation, les choses commencent à devenir faciles.

Answer 6

Si vous lisez un peu plus l'article, vous verrez ceci:

  

Pour les 5% d'applications où DDD   est un bon ajustement, c'est un très bon ajustement.   DDD aidera dans ces situations   vous casser une noix très difficile. Ici, DDD   peut être la solution miracle pour cela   loup-garou que votre gestionnaire vient   pointé vers votre bureau.

C’est la raison pour laquelle tant d’inquiétude.

Answer 7

• Comme votre application est principalement centrée sur les données, votre architecture pourrait être principalement conventionnelle.

• Pour les aspects où vous avez plus de logique et d'objets de domaine ou de valeur potentiels, vous pourriez peut-être exploiter certaines des idées DDD pour organiser le code.

• En général, l'option "alternative au son" est de garder les choses aussi simples que possible, d’utiliser les concepts DDD là où cela est utile, et de ne pas compliquer inutilement les choses, comme le dit l’article.

Je commence un projet similaire maintenant, c’est un mélange de manipulation de données et de domaines davantage axés sur la logique / algorithme. De même, j'aimerais prendre les éléments de DDD qui bénéficieront au projet, mais n'essayons pas de le forcer dans des domaines où il pourrait être contre-productif.