Was ist ein "Domain-Modell"?

Hallo Habr.

Heute bin ich zum #school-Kanal in der russischsprachigen GoCommunity in Slack gegangen und habe dort einen interessanten Dialog gefunden . Dieser Dialog führte mich zu einigen Gedanken darüber, wie meine Kollegen das Konzept des „Domänenmodells“ interpretieren.

Wie sich herausstellte, gibt es ziemlich viele falsche oder nicht ganz genaue und manchmal völlig ungenaue Interpretationen dieses Begriffs, was ihn wesentlich verzerrt. Um diesen Dialog herum wurde die Idee dieses Artikels geboren. Details unter dem Schnitt.

Frage zur Architektur.

Daher stellte der Entwickler in der Community die folgende Frage:

Sagen Sie mir, wie die Architektur korrekt ausgeführt wird. Nehmen wir an, ich habe ein Tablet in der Datenbank erstellt, die Reformen gebeten, ein Modell für mich zu generieren. Kann ich dieses Modell als Domänenmodell in meiner Anwendung verwenden oder ist es besser, ein eigenes Domänenmodell zu erstellen und einen Adapter zu erstellen, der mir genau mein Domänenmodell gibt es aus einem Reformmodell schaffen? “

Auf die ein anderer Programmierer folgende Antwort gab:

Am einfachsten ist die Architektur mit einem anämischen Modell. Dies ist der Fall, wenn das DB-Modell = Domänenmodell = API-Antwortmodell. Das Rich-Domain-Modell ist ein seltenes Tier und degeneriert normalerweise zu Anämien. Mit anämisch ist eine DTO-Struktur gemeint. die üblichen Attribute (Felder) ohne Methoden. Die Logik degeneriert zu einer Reihe von Funktionen, die mit einem solchen dto arbeiten. Fowler betrachtet eine solche Architektur manchmal als Antimuster. Aber dann eine gute Microservice-Lösung usw.

Nachdem ich dies gelesen hatte, wurde mir plötzlich klar, warum die Organisation der Geschäftslogikschicht so kontrovers diskutiert wird und warum viele Menschen Ansätze wie Clean Architecture usw. nicht in die Praxis umsetzen . Was bedeutet "Architektur mit einem anämischen Modell" ?

Wenn Sie versuchen, ein solches Konzept im Netzwerk zu finden, werden Sie es höchstwahrscheinlich nicht finden, da es keine solche Architektur gibt. Es gibt das Konzept von „AnemicDomainModel“ , und wenn wir uns demselben Fowler zuwenden, stellt sich heraus, dass dies nur ein prozeduraler Ansatz zum Erstellen einer Anwendungsarchitektur ist (Hallo Fortran, ALGOL, COBOL, BASIC, Pascal und C). Dies nennt der Autor der Antwort im Wesentlichen „Architektur mit einem anämischen Modell“ .

Das Domain-Modell.

Als nächstes stellt sich die nächste Frage: Ist das „anämische Modell“ im Wesentlichen ein Modell? Ich denke nicht, und deshalb.

Die Wahrheit ist, dass das Domänenmodell im Gegensatz zum „DB-Modell“ oder „API-Antwortmodell“ kein Datenmodell ist. Das Domänenmodell hat eine sehr spezifische Definition . Darüber hinaus ist es falsch, das Datenbankmodell zu stören, bei dem es sich im Wesentlichen um ein Datenmodell handelt .

Wenn es um das Domänenmodell geht, ist dies genau das konzeptionelle Modell. Und dies ist die Gesamtheit der Konzepte des Themenbereichs und der Beziehungen zwischen ihnen (d. H. Die Gesamtheit von Verhalten und Daten). Im Allgemeinen ist das Hauptmerkmal, das ein Modell eines Themenbereichs von einem anderen unterscheidet, genau ein Satz von Geschäftsregeln.

Ja, das konzeptionelle Modell kann mit Daten arbeiten, die in verschiedenen Formen dargestellt werden (Daten aus der Datenbank oder API-Antworten), aber das Wesentliche ändert sich nicht, das Verhalten ist von größter Bedeutung . Wir übergeben die Eingabe an das Modell, um eine bestimmte Ausgabe zu erhalten. Dieses Ergebnis wird durch die Implementierung der Geschäftslogik innerhalb des Modells erzielt (dh durch Anwenden von Geschäftsregeln). Ich finde hier eine Analogie zu mathematischen Modellen und zur Modellierung technologischer Prozesse (Hallo Studentenjahre).

Was ist mit der Substitution von Konzepten behaftet?

Wenn Sie Datenstrukturen als „Domänenmodell“ bezeichnen , können Sie Konzepte ersetzen oder nicht ersetzen. Dies führt dazu, dass die Geschäftslogik häufig in der gesamten Anwendung verteilt ist. Tatsächlich ist das Modell des Themenbereichs in diesem Fall der sehr verschmierte Satz von Funktionen, die mit Datenstrukturen arbeiten.

Bei der Entwicklung mittlerer und großer Anwendungen führt ein Missverständnis oder eine Vermischung dieser Konzepte in der Regel bereits zu Beginn der Systementwicklung zu einer Reihe von Problemen und Fragen, ganz zu schweigen von der langfristigen Unterstützung. Unter ihnen gibt es zum Beispiel häufig gestellte Fragen wie:

• "- Wo sollen die Daten validiert werden?"
• "- Wie vermeide ich zyklische Abhängigkeiten?"
• "- Ist" diese "Geschäftslogik im Allgemeinen?"
• "- Und wo bewahren wir die Geschäftslogik auf?"
• usw.

Wenn Sie eine einfache CRUD haben, d. H. Im Wesentlichen eine Schnittstelle zur Datenbank, wird es höchstwahrscheinlich keine Probleme geben. Wenn Sie eine Bibliothek auf Infrastrukturebene schreiben (z. B. für die Arbeit mit einem Netzwerk oder mit derselben Datenbank), sollten ebenfalls keine Probleme auftreten. Das liegt daran, dass es einen RFC gibt und alle „Geschäftsregeln“ seit langem klar sind und die Logik seit langem klar ist. Sie können ein einfaches prozedurales Programm schreiben, und alles wird sowieso gut.

Wenn wir auf die Tatsache zurückkommen, dass der Dialog über Domain-Modelle in der Go-Community entstanden ist, würde ich das sagen. Aufgrund der Tatsache, dass Go eine Multi-Paradigmen-Sprache ist und eine Reihe der erfolgreichsten OOP-Konzepte (Komposition, Schnittstellen) unterstützt, sollten Sie diese beim Modellieren einer Domäne nicht ignorieren und Code ausschließlich in einem prozeduralen Stil schreiben, als ob Sie mit BASIC oder C arbeiten.

Bei korrekter Interpretation des Konzepts des „Domänenmodells“ wird deutlich, warum es häufig üblich ist, Geschäftslogik in eine separate Ebene aufzuteilen. Es wird auch klar, wie Sie dieselbe Ebene auswählen und Clean Architecture oder eine andere Variante davon implementieren können. Indem wir eine separate Ebene isolieren, erstellen wir im Wesentlichen eine Bibliothek, die das konzeptionelle Modell in Form von Programmcode implementiert. Infolgedessen wird die Geschäftslogik im Rahmen dieser Bibliothek gekapselt und nicht in der gesamten Anwendung verteilt (wie bei einem reinen prozeduralen Ansatz).

Das Verständnis dieser Konzepte erspart Ihnen natürlich keine Konstruktionsfehler, macht Sie nicht zu einem idealen Entwickler oder Systemarchitekten und bringt Ihnen nicht bei, beim ersten Mal alles richtig zu machen. Hier ist nicht nur Theorie wichtig, sondern auch Praxis. Sobald Sie jedoch die Konzepte richtig verstehen und die Definitionen interpretieren, werden viele Dinge für Sie viel offensichtlicher und einfacher.

Zusammenfassend.

• Es ist nicht korrekt, "Daten" als Domänenmodell zu bezeichnen.
• Ein Domänenmodell ist ein konzeptionelles Modell, das sowohl Verhalten als auch Daten enthält. Es kann in einer separaten Schicht eingekapselt oder in der gesamten Anwendung verteilt werden.
• "Architektur mit einem anämischen Modell" ist nichts anderes als ein prozeduraler Ansatz zum Erstellen einer Anwendungsarchitektur, bei der das Domänenmodell über die gesamte Anwendung verteilt ist

Achten Sie auf Definitionen, studieren Sie sie tiefer als nur diagonal zu lesen. Sehr oft sind wir faul und greifen nach Informationen in Stücken, wonach es sicherlich zu Verzerrungen kommt. Vergessen Sie nicht, zurückzukommen und sich an Dinge zu erinnern, die Ihnen lange Zeit offensichtlich erscheinen, und beziehen Sie sich immer auf die Quellen und nennen Sie einen Spaten einen Spaten.

Gut zu allen! Vielen Dank für Ihre Aufmerksamkeit.

PS. Gerne höre ich konstruktive Kritik sowie Ihre Vision von einem „Domain-Modell“. Verweise auf die Quelle sind willkommen.

UPD: Der Artikel ist kein Versuch, das Konzept des "Domänenmodells" frei zu interpretieren und eine mir bekannte Bedeutung in dieses Konzept einzufügen. Ich möchte dies vermitteln: Die Bedeutung dieses Konzepts ist seit langem investiert und wird in Büchern und Artikeln über ComputerScience ausführlich beschrieben. Der Artikel ist ein Versuch, Kollegen die Wichtigkeit der korrekten Wahrnehmung dieser Konzepte zu vermitteln, ohne ihre Bedeutung zu verzerren (dies ist wichtig, da Sie in der Praxis aussagekräftigeren Code schreiben können).

UPD2: Ich bin kein Architekt eines Unternehmenstheoretikers. Ich bin der gleiche praktizierende Entwickler wie Sie. Ich schreibe jeden Tag Code und spreche über diese Dinge, um meinen Code besser und die Kunden zufriedener zu machen. Wenn ich Ihrer Meinung nach die ursprüngliche Bedeutung verzerrt habe, teilen Sie Links zur Quelle und geben Sie an, wo ich sie falsch platziert habe, damit ich sie beheben kann.

UPD3: Weil Viele interpretieren den Begriff „Themenbereich“ unterschiedlich. Ich gebe einige Beispiele für Themenbereiche, damit keine Verwirrung und Substitution von Konzepten entsteht. Der Themenbereich hängt immer davon ab, welches Problem Sie mit der Anwendungsentwicklung lösen:

• Tickets buchen (wenn Sie Entwickler von Reservierungssystemen sind)
• Banking (wenn Sie Entwickler von Bankanwendungen sind)
• Betriebssysteme (Wenn Sie ein Entwickler sind OS-Entwickler)
• Cloud-Infrastrukturmanagement (wenn Sie ein k8s-Entwickler sind)
• Virtualisierung (Wenn Sie ein Docker-Entwickler sind)
• Leistungsüberwachung (Wenn Sie ein Prometheus / Grafana-Entwickler sind)