Von der Schichtarchitektur bis zur DDD. Meine Erfahrung mit der Migration und dem Zerschneiden eines Monolithen

Heute sprechen wir über die Architektur von Backend-Anwendungen und vergleichen zwei beliebte Methoden zur Strukturierung von Projekten: Onion und DDD. Ich erzähle Ihnen von den Vorteilen des zweiten Ansatzes gegenüber dem ersten und von meinen jüngsten Erfahrungen bei der Übertragung eines Projekts auf sechseckige Architektur. Dieser Text richtet sich an diejenigen, die bereits mit geschichteter Architektur gearbeitet haben und mehr wollen (z. B. mit der Arbeit mit Microservices beginnen).

Beginnen wir mit der Schichtarchitektur. Layered, auch Zwiebelarchitektur genannt, ist eine Architektur, bei der wir die gesamte Anwendung in Schichten unterteilen. Jede Schicht hat ihre eigene Funktion, ihren eigenen klaren Zweck. Zum Beispiel Interaktion mit der Datenbank: Eine solche Schicht sollte ausschließlich Funktionen zur Interaktion mit der Datenbank enthalten und sonst nichts. Es sollte keine Interaktion mit dem Client oder anderen Funktionen stattfinden.

Oft gibt es in einer Schichtarchitektur drei Hauptschichten im Backend: für die Interaktion mit dem Speicher, die Anwendungslogik und eine repräsentative Schicht.

Hier ist eine typische dreischichtige Architektur, alles daran ist recht einfach. Die Anfrage durchläuft alle Schichten und erhält die endgültige Form (Anfrage im Speicher), die Antwort macht den Rückweg und wird in ein für den Client geeignetes Format umgewandelt (JSON, XML usw.).

Ich verwende diese Architektur schon seit geraumer Zeit in allen meinen Projekten und in dem Startup, an dem ich beteiligt bin. Bei kleinen Lieblingsprojekten funktioniert dieser Ansatz wirklich und verursacht keine Probleme, aber bei größeren Projekten beginnt das Chaos.

Eines der Hauptprinzipien der Schichtenarchitektur ist die Möglichkeit, jede Schicht durch eine ähnliche zu ersetzen, sodass keine andere Schicht überhaupt geändert werden muss. Aber in Wirklichkeit ist es umso schwieriger, die Anforderungen einzuhalten, je mehr Entitäten in einem Projekt vorkommen.

Zuerst tauchen zu viele Abhängigkeiten auf und es wird immer schwieriger, diese zu kontrollieren. Dies impliziert die Vernachlässigung des Monolithen (schließlich ist Onion eine monolithische Architektur). Die Last wird nicht richtig verteilt und die Anwendung ist überlastet. Darüber hinaus beginnen sich die Schichten zu vermischen – es wird immer schwieriger, die Anwendungslogik zu isolieren. Es wird immer schwieriger, die Anwendung zu erweitern, Abhängigkeiten machen das Debuggen zur Hölle und die Entwicklung verlangsamt sich erheblich. Treibstoff ins Feuer gießen sind strenge Architekturmuster, die die Möglichkeiten des Entwicklers einschränken. Wenn Sie diesen Text lesen, ist Ihnen dies wahrscheinlich bereits begegnet. Die gleiche Situation trat in unserem Projekt auf.

Natürlich ist es in einer solchen Situation notwendig, den Monolithen zu zerschneiden, zu einer anderen Architektur zu wechseln und freiere Muster einzuführen. Wir haben uns für DDD entschieden, es schien eine naheliegende Lösung zu sein. DDD (Domain Driven Design, hexagonale Architektur) ist eine Microservice-Architektur (obwohl sie als monolithische Architektur verwendet werden kann), die auf Abstraktionen basiert. Wenn Sie nur Erfahrung mit der Arbeit mit mehrschichtiger Architektur haben, können Sie sich als grobes Beispiel dieselbe dreischichtige Architektur vorstellen, bei der anstelle einer Schicht der Interaktion mit dem Speicher eine Schicht der Interaktion mit allen Technologien im Allgemeinen vorhanden ist, und das gibt es auch eine separate Ebene mit Abstraktionen. Abstraktionen sind im Allgemeinen die Hauptsache in DDD. Diese Abstraktionen sowie Hilfstools und Demonstrationseinheiten (Vorlagen, Diagramme) sind von der Anwendung getrennt, sodass die Architektur wie folgt aussieht:

Der Hauptvorteil der heskagonalen Architektur gegenüber der geschichteten Architektur ist die Erweiterbarkeit. Es ist viel einfacher, neue Features, neue Parameter und neue Funktionen zu implementieren, da es weniger Abhängigkeiten gibt.

Zuerst kam mir diese Struktur völlig unlogisch vor, aber im Zuge der Umstellung auf DDD stellte ich fest, dass das Schreiben viel einfacher wurde, da die Infrastruktur selbst aus der untersten Ebene der Anwendung und dort vollständig entfernt wurde Es gab weniger Abhängigkeiten. Es gab sogar eine Art irrationale Erleichterung und plötzliche Handlungsfreiheit über jedes Wesen. Dieser Ansatz erscheint mir mittlerweile noch logischer als die Schichtarchitektur.

Aber Sie müssen bedenken, dass eine solche Architektur keinen Sinn ergibt, wenn das Projekt 2-3 Entitäten enthält, da DDD hauptsächlich als Microservice-Architektur in Anwendungen mit einer großen Anzahl von Abhängigkeiten verwendet wird, die einfach nicht vorhanden sein können kleine Lieblingsprojekte mit 2-3 Wesenheiten. An manchen Stellen reicht sogar eine einfache lineare Architektur aus. Und im Allgemeinen ist die unnötige Verwendung verschiedener Technologien und Praktiken eine schlechte Praxis, es sei denn, Sie entscheiden sich, zu experimentieren, um zu lernen.

P.S. Und Sie müssen sich für TGC begeistern: https://t.me/dmkjfss

Das obige ist der detaillierte Inhalt vonVon der Schichtarchitektur bis zur DDD. Meine Erfahrung mit der Migration und dem Zerschneiden eines Monolithen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!