Il y a un an, Maxim Arshinov (marshinov) a fait une présentation "Instant Design". Excellent rapport, conférencier charismatique, matériel utile à la fin. Ce rapport a changé ma compréhension de ce que je faisais - lequel d'entre nous n'a pas essayé d'appliquer intuitivement l'architecture de pipeline? Et puis il y a des solutions élégantes multipliées par DDD! Cela a commencé mon voyage en tant qu'évangéliste dans la conception spécifique au domaine.

DotNext 2019 Moscou arrive bientôt. Comme toujours, nous attendons un examen des nouvelles fonctionnalités, des échanges d'expériences, des meilleures pratiques, des solutions architecturales - pour cela, nous aimons tous les conférences. Dans la liste des rapports se trouve le wokshop «L' éclat et la pauvreté du modèle sujet», qui a attiré mon attention. Citation de la page:

Fowler et Evans considèrent que le modèle anémique est anti-modèle. Cependant, de nombreuses bases de code avec lesquelles le locuteur a travaillé sont implémentées dans le style d'un modèle anémique. Le rapport est consacré à comparer les forces et les faiblesses des deux approches et les détails non évidents de la mise en œuvre du modèle de domaine dans le paradigme OOP et dans le style fonctionnel.

La production elle-même fait penser qu'une crise est apparue dans le développement du mouvement DDD. Une petite analyse des dysfonctionnements d'utilisation et les raisons de ces distorsions sous la coupe.

Dysfonctionnements de l'utilisation de la conception orientée sujet

La situation actuelle connaît un certain développement historique. Examinons par étapes l'évolution de la situation.

La promotion

Maxim, à mon avis, est le développeur le plus célèbre de la communauté, qui pendant de nombreuses années a promu DDD avec compétence, en parlant du concept, de l'utilisation. Honorez-le et louez-le! Et je donne comme exemple Arshinov, uniquement parce que je le considère comme le meilleur orateur de dotnext pour le moment.

Dysfonctionnement n ° 1: rentabilité

marshinov a écrit plusieurs articles sur le coût de la mise en œuvre des pratiques DDD. La conclusion est simple - la conception orientée sujet coûte cher. Et les jugements sont justes - Evans lui-même dans son livre note que l'équipe doit être très compétente et donc chère. De plus, ce sont des améliorations continues, ce qui coûte cher pour une entreprise. Révèle bien cet article de Martin Fowler sur les coûts de l'architecture . J'ose supposer que la question de savoir combien une entreprise veut dépenser des ressources est d'abord la solution de ses problèmes à elle-même. Et le client ne résout pas lui-même de problèmes majeurs, alors même SOLID ne pourra pas le vendre.

Il est très important de comprendre l'antagonisme des exigences commerciales et des décisions architecturales. Les entreprises ont besoin de la solution la moins chère qui couvrira leurs besoins (et mieux la première fois et pour toujours). Les équipes veulent créer des outils et des solutions qui résolvent le plus correctement, rapidement et magnifiquement les problèmes commerciaux, mais surtout la tâche d'adaptabilité aux changements. La nature de ces besoins (en fait, les contradictions polaires) est très dialectique, ce qui signifie qu'il est impossible de réaliser des exigences complexes sans élaborer l'architecture, et les copropriétés ne peuvent pas être construites à la place d'une niche. Non, bien sûr, tout est possible. Mais le fait est que les exigences élevées d'une part donnent lieu à la correspondante d'autre part. Comme la faiblesse pathologique d'un côté, elle limite l'autre.
Et donc, dans une tentative de faire correspondre l'entreprise, une deuxième catastrophe s'est formée ...

Dysfonctionnement n ° 2: Instant Design aka Anemic Model aka Consent

De toute évidence, une certaine communauté de programmeurs essaie d'apporter aux masses de pratiques une conception orientée sujet moins chère, en réduisant les coûts et en appliquant de nouvelles techniques: programmation ferroviaire, pipelines, modèle anémique. Une approche cool, beaucoup conseillent, cela peut être enseigné à n'importe quel programmeur: "ici vous avez SeedWorks avec des interfaces, implémentez-les et tout sera." Et ça marche! mais ce n'est pas DDD.

Vous ne comprenez pas très bien Evans.

• Qui ne loue pas Klopstock? Mais est-ce que tout le monde le lira? Non. Nous voulons être moins vénérés, mais lisez plus attentivement! (Lessing).

Je vais vous expliquer maintenant.

Le modèle anémique est un contre-modèle

Le fait est qu'en science il existe deux méthodes de recherche - descriptive et analytique (bonjour Adam Smith). Lorsque nous créons le modèle anémique, nous décrivons simplement ce que nous voyons et vivons avec lui tel quel. Cela reflète une entreprise et est suffisant pour réaliser une opportunité commerciale. Un principe important décrit par Evans n'est pas de gaspiller des ressources sur un système idéal, mais de simuler le processus tel qu'il est et de ne commencer ensuite que le refactoring en profondeur. Et à quel moment avec le modèle anémique peut-on passer à une refactorisation profonde? Est-il censé le démarrer? Il me semble que la réponse sera négative, et le modèle ici est resté comme l'atavisme.

C'est juste que le modèle lui-même n'est pas important! Les modèles tactiques ne sont pas importants! Des contextes limités, une seule langue et une structure à grande échelle sont importants. C'est pourquoi il est nécessaire d'approcher l'entité commerciale du côté analytique, en décrivant la racine d'agrégation, les objets de valeur, les méthodes commerciales et, par conséquent, de comprendre les limites d'un contexte limité.

D'une part, un modèle anémique et une solution bon marché sont bons, car les programmeurs débutants auront une compréhension d'une nouvelle dimension de la programmation - les objets métier. Cependant, en adoptant une position similaire, vous vous débrouillez mal. En embauchant à chaque fois un programmeur plus faible qui peut faire à peu près la même chose que le copier-coller, avez-vous un argument pour que l'entreprise recherche un employé plus fort?

Mais cela ne pouvait pas se terminer avec la fin peu glorieuse de l'idée DDD.

Dysfonctionnement n ° 3 La vie après les objets métier alias complication des outils.

Au printemps 2019, Maxim et Wagib nous ont expliqué comment les fonctionnalités de F # en C # ne sont pas venues, comment rendre le modèle correctement en F # est plus facile, comment comment le fonctionnalisme pour ne pas violer la POO. Maintenant, les masses pouvaient croire que DDD n'était pas seulement abordable pour commander de la musique, mais pas pour tous les mortels, mais seulement pour ceux qui connaissaient la programmation fonctionnelle.

Écoutez où ils conduisent tous - maintenant, la conception orientée sujet coûte cher, vous pouvez effectivement écrire uniquement en F #, et fonctionne généralement parfois, parfois. Il n'y a aucune faible impression que de cette façon, les auteurs de livres et d'articles nous distraient des plus importants du DDD, attirant le jeu avec des schémas tactiques idéaux. Et ils doivent être beaux et léchés, sinon ...

Bien sûr, il n'y a pas d'autre moyen. Toutes ces abstractions sont importantes dans une conversation BrainSrorm, lorsque tout le monde a besoin de tout comprendre très clairement. Ou si vous trouvez des gestionnaires et des analystes qui examineront votre code - une seule langue (si le code est UL).

Cependant, comme mentionné ci-dessus, l'inverse cherchera sa propre voie. L'approche a pris racine là où l'entreprise est prête à payer pour le développement d'un code fonctionnellement non évident - ce n'est qu'une niche de marché, pas une règle.

Ce qui est absolument dégoûtant ici, c'est la nature humaine simple de l'attitude envers les réalisations - les gens apprécient ces réalisations en elles-mêmes, sans leur donner de formulaire et d'application. Et ici, la liste peut être longue. Einstein nous a donné STO, GR, FE, c'est un excellent scientifique, mais interrogez la personne moyenne sur le mouvement relativiste, le temps - il n'a pas besoin d'Einstein, mais dans une conversation «intelligente», on pourrait mentionner que tout est relatif. Demandez à une personne au sujet de Freud, un grand psychologue qui a fait de sérieux progrès scientifiques, si cette personne utilise la psychologie, par exemple, pour interpréter le cauchemar d'hier - il ne le fera pas, mais il mentionnera un jour la sexualité et la psychologie des masses. Marx est celui qui a fait la science de la sociologie et de l'histoire, mais personne n'a besoin du socialisme scientifique, mais tout le monde peut parler d'impôt progressif et de démocratie honnête. La conception axée sur les problèmes n'a également aucune forme - Eric Evans nous a ouvert de nouveaux horizons, fournissant un excellent outil pour réduire la complexité des logiciels, mais apparemment la façon d'utiliser DDD et ce qu'il faut faire n'est pas claire, et généralement cela ne fonctionne pas du tout.

Je ne sais pas comment pour le reste, mais avec la conception orientée sujet, vous pouvez comprendre les raisons des malentendus.

Les raisons de la crise d'utilisation

Les principes de la conception orientée sujet sont très tentants, logiques et holistiques. Tout est proche ici - Agile, CI, SOLID, GRASP - tout le meilleur que les développeurs ont trouvé. Cependant, il ne suffit pas de croire au DDD, aux affaires ou à l'expérience. Beaucoup de gens de la communauté, juste des développeurs d'intégrateurs et de bureaux d'externalisation, ont l'empreinte des valeurs commerciales dans leur travail, et avec le désir qu'ils ne peuvent pas essayer les méthodes et les pratiques de pointe, parce que le prix de ces essais et erreurs n'est pas inclus dans la liste de prix - c'est une finale complètement matérialiste.

Il n'y a absolument plus rien pour de telles commandes, sauf comment rentabiliser la programmation, en utilisant des approches plus simples, en embauchant des développeurs moins chers, mais un modèle anémique peut être accroché en une demi-bouchée. Et si vous êtes le développeur de l'un des développeurs qui viennent pour une heure - vous n'avez pas de perspectives importantes - vous devez terminer la commande, et la créativité n'est encouragée que sur le github dans le projet d'accueil. DDD n'est pas un luxe pour un architecte, pas une démonstration de clientèle - le niveau d'équipe dans une entreprise distincte. Vous devez réaliser ce qui suit - pendant que vous êtes dans une relation de production avec ceux qui vendent votre travail qualifié à ceux qui paient mieux, vous ne ferez que ce que le client a payé - la mise en œuvre de tâches commerciales. Malheureusement, tester les meilleures pratiques ne se situe pas toujours dans le plan de ces tâches.

Résumé

DDD peut toujours être essayé si vous décrivez des objets du monde réel. Cette approche peut être appliquée en PHP, et en VBA, et 1C (et les développeurs s'appliquent). Le problème de l'application de l'approche est plus probable dans le plan de la communication entre les personnes, et la technologie est plus susceptible d'aider. Communiquez, essayez, enseignez aux autres! Boostez Softskills, solidarité, unité d'objectif. DDD est juste une technique de travail d'équipe.

Et la prochaine fois que vous penserez où aller pour un entretien, réfléchissez bien à ce que vous choisissez - une entreprise qui revend sans pitié vos compétences ou qui en a vraiment besoin pour résoudre des problèmes spécifiques. Il est en votre pouvoir d'aider une telle entreprise à être meilleure, à essayer des méthodes et des approches proportionnées, à former une équipe soudée, à remplir votre mission de programmeur. Ce dernier est particulièrement important, car pour les nouvelles technologies et les goodies, beaucoup ont oublié l'objectif initial de cette profession.

Quoi qu'il en soit, il reste à espérer qu'en essayant de toucher aux meilleures pratiques, DDD ne sera pas transformé dans une autre direction pour des raisons de commodité pour les clients et les équipes. J'attends avec impatience le prochain rapport.

PS L'objectif du sujet est une invitation à une discussion. Il n'y a aucun but de minimiser le mérite des membres de la communauté DDD. Avec respect, je traite tous les représentants, ce qui n'élimine pas les problèmes de développement.