Est-ce que DDD est une perte de temps?

Question

Googler "Ce type d'applications est DDD approprié pour?" m'a donné la réponse suivante:

Probablement 95% de toutes les applications logicielles tomber dans le "pas très bon pour l'utilisation de DDD" des catégories. (voir l'article)

Donc, qu'est-ce que toutes ces histoires?!?

L'application que je suis en train de travailler sur est principalement centrée sur les données, mais contient toujours un peu de logique métier et des règles à appliquer. Serait-il perte de temps pour commencer à appliquer DDD techniques? Suis-je mieux d'utiliser un plus classiques Couche d'Accès aux Données, un modèle de Poco et une Couche de Logique Métier? Ou pour dire les choses différemment, ce qui est une bonne alternative à DDD?

Answer 1

De nombreux développeurs qui pensent que DDD est utile pour leur projet tomber dans le piège qu'ils pensent que leur travail est tout au sujet est l'écriture de code. Ce n'est pas le cas. Un développeur d'emploi est à propos de la réalisation de la fonctionnalité de sorte qu'un problème peut être résolu par le logiciel. Cela aboutit à la conclusion que l'écriture de code n'est pas le début de ce qu'un développeur est en train de faire, mais à la fin: le code est le résultat de l'ensemble du processus AVANT que le code est écrit.

DDD n'est pas à propos de l'écriture de code, ce n'est pas un processus en 10 étapes pour obtenir un excellent logiciel, c'est sur que tout le processus AVANT que le code est écrit, il s'agit d'obtenir un aperçu de ce que le problème est tout au sujet, ce/qui participe dans lequel les flux d'informations et de quoi ces éléments ressemblent, comment ils se rapportent à d'autres personnes etc. etc. En fait, la partie la plus importante de DDD est la création d'un langage qui rend les conversations entre les experts du domaine et les développeurs possible sans erreurs d'interprétation. C'est le "Ubiquitous Language' Evans parle. Il rend en effet l'ensemble du processus AVANT le code est écrit par un processus qui laisse peu de place à l'aurez deviné, les choses sont claires et directes. (c'est le but).

Le problème avec les "comment est-DDD travail dans la pratique" et "quelqu'un pourrait-il me donner un exemple de la façon dont j'écris le code avec DDD?" et la comme vient vraiment du fait que les gens demandent à ce genre de questions se concentrer sur l'écriture de code, mais n'ont aucune idée de POURQUOI ils sont en train d'écrire le code et pas un autre code. I. o.w.: si vous vous rendez compte que DDD sujet de la découverte de CE que vous avez à écrire que la fonctionnalité et le POURQUOI, les choses tombent en place. COMMENT vous écrivez que le code, c'est à vous. Mais, comme on dit: ce n'est pas le plus gros problème, comme vous l'avez déjà savoir ce que vous avez à écrire, et pourquoi.

Answer 2

Désolé, mais si DDD étaient seulement une manière de penser qu'Frans Bouma a dit, alors il ne vous recommanderais pas de choses telles que la Persistance de l'Ignorance. C'est en rejetant les autres, un peu comme sous-classe de développeurs.

PI, pour qui DDD a au moins un parti pris, est un choix architectural. Ce n'est pas une façon de penser plus ; c'est déjà quelque chose qui est servi à vous, avec la plupart du temps trop vague avertissements pour être d'une quelconque utilité: "qui n'est pas adapté pour tout".

Mais de décider d'aller la PI ou non est un défi en soi, et vous ne pouvez pas appeler les noms quelqu'un (un"codeur") si il se sent mal à l'aise à ce sujet.

Prendre un ERP avec tous les lieu d'un MS Access-comme l'interface: les grilles avec des cumuls de l'auto-mise à jour de colonnes et pageless à défiler sur les 100 000 entrées. Clairement un DDD approche est adaptée à la pensée de la façon d'aller sur cette application. Mais dans les années je n'ai jamais vu personne - ni dans les livres ni sur internet, en allant bien étayé explications, sans parler de la vie réelle des exemples de code, de combien de PI pourrait traiter ce omniprésente de la situation pour tous ceux qui veulent livrer de la qualité commerciale des applications et des expériences utilisateur.

Ne voulez pas d'obtenir religieuse sur cette. DDD et DAL promoteurs ont tendance à être trop religieux et peut conduire à l'écart de ceux qui ont été mordu une fois, mais qui sont/étaient ouverts d'esprit. De nombreux veux juste de confronter les expériences réelles (c'est à dire le PENSE), et ne pas avoir servi avec des Chats, des Voitures, et l'Ordre de base/OrdersItems (c'est à dire mauvais CODE) à l'appui de la prédication.

Answer 3

Voici une question très similaire: http://stackoverflow.com/questions/796656/do-you-allow-the-web-tier-to-access-the-dal-directly/796961#796961

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 4

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 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 5

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

Pour les 5% d'applications où DDD est un bon ajustement, c'est un très bon ajustement. Pour ces situations, DDD vous aidera à résoudre un problème très difficile. Ici, DDD peut être la solution miracle pour ce loup-garou que votre responsable vient de désigner.

C'est pourquoi le bruit a ce sujet.