Vor einem Jahr hielt Maxim Arshinov (Marshinov) eine Präsentation "Instant Design". Toller Bericht, charismatischer Redner, nützliche Materialien am Ende. Dieser Bericht veränderte mein Verständnis von dem, was ich tat - wer von uns hat nicht versucht, die Pipeline-Architektur intuitiv anzuwenden? Und dann gibt es elegante Lösungen multipliziert mit DDD! Dies begann meine Reise als Evangelist in domänenspezifischem Design.

DotNext 2019 Moskau kommt bald. Wie immer warten wir auf eine Überprüfung neuer Funktionen, Erfahrungsaustausch, Best Practices und architektonische Lösungen - dafür lieben wir alle Konferenzen. In der Liste der Berichte steht der Wokshop „Der Glanz und die Armut des Subjektmodells “, der meine Aufmerksamkeit auf sich zog. Zitat von der Seite:

Fowler und Evans betrachten das anämische Modell als Antimuster. Viele Codebasen, mit denen der Sprecher gearbeitet hat, sind jedoch im Stil eines anämischen Modells implementiert. Der Bericht widmet sich dem Vergleich der Stärken und Schwächen beider Ansätze und der nicht offensichtlichen Details der Implementierung des Domänenmodells im OOP-Paradigma und im funktionalen Stil.

Die Produktion selbst lässt vermuten, dass in der Entwicklung der DDD-Bewegung eine Krise aufgetreten ist. Eine kleine Analyse der Funktionsstörungen und der Gründe für solche Verzerrungen unter dem Schnitt.

Funktionsstörungen bei der Verwendung von themenorientiertem Design

Die gegenwärtige Situation hat eine historische Entwicklung. Betrachten wir schrittweise, wie sich die Situation entwickelt hat.

Förderung

Maxim ist meiner Meinung nach der bekannteste Entwickler in der Community, der DDD über viele Jahre kompetent bewarb und über das Konzept und die Verwendung sprach. Ehre ihn und lobe! Und ich gebe Arshinov als Beispiel, nur weil ich ihn momentan für den besten Sprecher von dotnext halte.

Funktionsstörung Nr. 1: Rentabilität

Marshinov hat mehrere Artikel über die Kosten für die Implementierung von DDD-Praktiken verfasst. Das Fazit ist einfach - themenorientiertes Design ist teuer. Und die Urteile sind fair - Evans selbst schreibt in seinem Buch, dass das Team sehr geschickt und daher teuer sein muss. Darüber hinaus handelt es sich um kontinuierliche Verbesserungen, die für ein Unternehmen teuer sind. Gut enthüllt dieser Themenartikel von Martin Fowler über die Kosten der Architektur . Ich wage anzunehmen, dass die Frage, wie viel ein Unternehmen Ressourcen ausgeben möchte, die Lösung seiner Probleme ist, vor allem für sich. Und der Kunde löst selbst keine größeren Probleme, dann kann ihn auch SOLID nicht verkaufen.

Es ist sehr wichtig, den Gegensatz von Geschäftsanforderungen und Architekturentscheidungen zu verstehen. Unternehmen benötigen die günstigste Lösung, die ihre Anforderungen abdeckt (und besser beim ersten Mal und für immer). Teams möchten Tools und Lösungen entwickeln, die geschäftliche Probleme am korrektesten, schnellsten und schönsten lösen, insbesondere aber die Aufgabe der Anpassungsfähigkeit an Änderungen. Die Art dieser Bedürfnisse (in der Tat polare Widersprüche) ist sehr dialektisch, was wiederum bedeutet, dass es unmöglich ist, komplexe Anforderungen ohne Ausarbeitung der Architektur zu realisieren, und Eigentumswohnungen können nicht anstelle einer Hundehütte gebaut werden. Nein, natürlich ist alles möglich. Fakt ist aber, dass hohe Anforderungen einerseits zu entsprechenden Anforderungen führen. Wie die pathologische Schwäche einer Seite begrenzt sie die andere.
Und so entstand bei dem Versuch, dem Geschäft zu entsprechen, eine zweite Katastrophe ...

Dysfunktion Nr. 2: Sofortiges Design alias anämisches Modell alias Zustimmung

Offensichtlich versucht eine bestimmte Gemeinschaft von Programmierern, ein billigeres themenorientiertes Design in die Masse der Praktiken zu bringen, Kosten zu senken und neue Techniken anzuwenden: Eisenbahnprogrammierung, Pipelines, anämisches Modell. Ein cooler Ansatz, den viele raten, der jedem Programmierer beigebracht werden kann: "Hier haben Sie SeedWorks mit Schnittstellen, implementieren diese und alles wird sein." Und es funktioniert! Dies ist jedoch nicht DDD.

Sie verstehen Evans nicht ganz.

• Wer lobt Klopstock nicht? Aber wird es jeder lesen? Nein. Wir wollen weniger verehrt werden, aber fleißiger lesen! (Lessing).

Ich werde es jetzt erklären.

Das anämische Modell ist ein Antimuster

Tatsache ist, dass es in der Wissenschaft zwei Forschungsmethoden gibt - beschreibende und analytische (Hallo Adam Smith). Wenn wir das anämische Modell erstellen, beschreiben wir einfach , was wir sehen, und leben damit, wie es ist. Dies spiegelt ein Geschäft wider und reicht aus, um eine Geschäftsmöglichkeit zu realisieren. Ein wichtiges Prinzip, das von Evans beschrieben wird, besteht nicht darin, Ressourcen für ein ideales System zu verschwenden, sondern den Prozess so zu simulieren, wie er ist, und erst dann mit dem tiefgreifenden Refactoring zu beginnen. Und ab wann können wir mit dem anämischen Modell zu tiefgreifendem Refactoring übergehen? Soll es überhaupt anfangen? Es scheint mir, dass die Antwort negativ sein wird, und das Modell hier blieb als Atavismus.

Das ist nur das Modell selbst ist nicht wichtig! Taktische Muster sind nicht wichtig! Begrenzte Kontexte, eine einzige Sprache und eine große Struktur sind wichtig. Aus diesem Grund ist es erforderlich, sich von der analytischen Seite an die Geschäftseinheit zu wenden, die Aggregationswurzel, Wertobjekte und Geschäftsmethoden zu beschreiben und als Ergebnis die Grenzen eines begrenzten Kontexts zu verstehen.

Ein anämisches Modell und eine kostengünstige Lösung sind einerseits gut, da angehende Programmierer eine neue Dimension der Programmierung verstehen - Geschäftsobjekte. Wenn Sie jedoch eine ähnliche Position einnehmen, tun Sie sich schlecht. Haben Sie ein Argument dafür, dass das Unternehmen nach einem stärkeren Mitarbeiter sucht, indem Sie jedes Mal einen schwächeren Programmierer einstellen, der fast das Gleiche wie Kopieren und Einfügen kann?

Aber es konnte nicht mit dem unrühmlichen Ende der DDD-Idee enden.

Dysfunktion Nr. 3 Leben nach Geschäftsobjekten, auch bekannt als Komplikation von Werkzeugen.

Im Frühjahr 2019 erzählten uns Maxim und Wagib, wie die Funktionen von F # in C # nicht entstanden sind, wie es einfacher ist, das Modell in F # korrekt zu machen, wie man im Funktionalismus OOP nicht verletzt. Jetzt konnten die Massen glauben, dass DDD nicht nur für die Bestellung von Musik nicht erschwinglich war, sondern nicht für alle Sterblichen, sondern nur für diejenigen, die sich mit funktionaler Programmierung auskannten.

Hören Sie, wohin sie alle fahren - jetzt ist themenorientiertes Design teuer, Sie können effektiv nur in F # schreiben und funktionieren im Allgemeinen manchmal, manchmal. Es gibt keinen schwachen Eindruck, dass die Autoren von Büchern und Artikeln uns auf diese Weise von den wichtigsten in DDD ablenken und das Spiel mit idealen taktischen Mustern anlocken. Und sie müssen schön sein und geleckt werden, sonst ...

Natürlich gibt es keinen anderen Weg. All diese Abstraktionen sind wichtig in einem BrainSrorm-Gespräch, wenn jeder alles sehr klar verstehen muss. Oder wenn Sie Manager und Analysten finden, die sich Ihren Code ansehen - eine einzige Sprache (wenn der Code UL ist).

Wie oben erwähnt, wird das Gegenteil jedoch seinen eigenen Weg suchen. Der Ansatz hat Wurzeln geschlagen, wo das Unternehmen bereit ist, für die Entwicklung von funktional nicht offensichtlichem Code zu zahlen - dies ist nur eine Marktnische, keine Regel.

Was hier absolut widerlich ist, ist die einfache menschliche Natur der Einstellung zu Leistungen - Menschen schätzen solche Leistungen an sich, ohne ihnen eine Form und eine angewandte Anwendung zu geben. Und hier kann die Liste lang sein. Einstein gab uns STO, GR, FE, er ist ein ausgezeichneter Wissenschaftler, aber fragen Sie den Durchschnittsmenschen nach der relativistischen Bewegung, Zeit - er braucht Einstein nicht, aber in einem "klugen" Gespräch könnte man erwähnen, dass alles relativ ist. Fragen Sie eine Person nach Freud, einem hervorragenden Psychologen, der ernsthafte Fortschritte in der Wissenschaft gemacht hat, ob diese Person beispielsweise Psychologie verwendet, um den gestrigen Albtraum zu interpretieren - er wird es nicht tun, aber er wird eines Tages die Sexualität und die Psychologie der Massen erwähnen. Marx ist derjenige, der Wissenschaft aus Soziologie und Geschichte gemacht hat, aber niemand braucht wissenschaftlichen Sozialismus, aber jeder kann über progressive Steuern und ehrliche Demokratie sprechen. Problemorientiertes Design hat auch keine Form - Eric Evans hat uns neue Höhen eröffnet und bietet ein hervorragendes Werkzeug zur Reduzierung der Softwarekomplexität, aber angeblich ist nicht klar, wie DDD verwendet wird und was zu tun ist, und im Allgemeinen funktioniert es überhaupt nicht.

Ich weiß nicht, wie es mit dem Rest weitergeht, aber mit dem themenorientierten Design können Sie die Gründe für die Missverständnisse verstehen.

Die Gründe für die Nutzungskrise

Die Prinzipien des themenorientierten Designs sind sehr verlockend, logisch und ganzheitlich. Hier ist alles in der Nähe - Agile, CI, SOLID, GRASP - alles Gute, was sich die Entwickler ausgedacht haben. Es reicht jedoch nicht aus, an DDD, Geschäft oder Erfahrung zu glauben. Viele Leute aus der Community, nur Entwickler von Integratoren und Outsourcing-Büros, haben den Eindruck von Geschäftswerten in ihrer Arbeit und können bei allem Wunsch die führenden Methoden und Praktiken nicht ausprobieren, da der Preis für diese Versuche und Irrtümer nicht in der Preisliste enthalten ist - es ist ein vollständig materialistisches Finale.

Es gibt absolut nichts mehr für solche Befehle übrig, außer wie man die Programmierung rentabel macht, einfachere Ansätze verwendet und Entwickler billiger anstellt, aber ein anämisches Modell kann "um einen halben Zoll" gehakt werden. Und wenn Sie der Entwickler eines der Entwickler sind, die für eine Stunde kommen - Sie haben keine nennenswerten Aussichten -, müssen Sie den Auftrag abschließen, und Kreativität wird nur auf dem Github im Heimprojekt gefördert. DDD ist kein Luxus für einen Architekten, kein Kunden-Show-Off - die Teamebene in einem separaten Unternehmen. Sie müssen Folgendes realisieren: Während Sie in einer Produktionsbeziehung mit denen stehen, die Ihre Facharbeit an diejenigen verkaufen, die besser bezahlen, werden Sie nur das tun, wofür der Kunde bezahlt hat - die Implementierung von Geschäftsaufgaben. Leider liegt das Testen von Best Practices nicht immer in der Ebene dieser Aufgaben.

Zusammenfassung

DDD kann immer dann ausprobiert werden, wenn Sie reale Objekte beschreiben. Dieser Ansatz kann in PHP, VBA und 1C angewendet werden (und die Entwickler wenden ihn an). Das Problem bei der Anwendung des Ansatzes liegt eher in der Kommunikationsebene zwischen Menschen, und Technologie hilft eher. Kommunizieren, versuchen, andere lehren! Steigern Sie Softskills, Solidarität, Einheit des Zwecks. DDD ist nur eine Teamarbeitstechnik.

Und wenn Sie das nächste Mal darüber nachdenken, wo Sie ein Interview führen sollen, überlegen Sie genau, was Sie wählen - ein Unternehmen, das Ihre Fähigkeiten gnadenlos weiterverkauft oder das sie wirklich benötigt, um bestimmte Probleme zu lösen. Es liegt in Ihrer Macht, einem solchen Unternehmen zu helfen, besser zu werden, angemessene Methoden und Ansätze auszuprobieren, ein engmaschiges Team zu bilden und Ihre Mission als Programmierer zu erfüllen. Letzteres ist besonders wichtig, da viele für neue Technologien und Extras den ursprünglichen Zweck dieses Berufs vergessen haben.

Wie dem auch sei, es bleibt zu hoffen, dass DDD beim Versuch, die führenden Praktiken zu berühren, aus Gründen der Bequemlichkeit für Kunden und Teams nicht in eine andere Richtung transformiert wird. Ich freue mich auf den kommenden Bericht.

PS Der Zweck des Themas ist eine Einladung zu einer Diskussion. Es besteht kein Zweck, die Verdienste von Mitgliedern der DDD-Gemeinschaft herabzusetzen. Mit Respekt behandle ich alle Vertreter, was die Entwicklungsprobleme nicht beseitigt.