Anwendungsarchitektur oder wie man Karma auf Habré verdirbt

Sie können viel über Anwendungsarchitektur, SOLID, OOP-Prinzipien, Architekturmuster wie Layered oder Onion usw. sprechen. Designmuster. Während meiner Erfahrung wurde mir klar, wie viele Menschen so viele Meinungen haben. Wenn Sie ein Anfängerprogrammierer sind, haben Sie viele Ambitionen, Sie wachsen ein wenig in der Qualifikation, Sie haben das Gefühl, dass Sie alles wissen und alles, was Ihnen angetan wurde, ist „schlecht“, und Sie werden es definitiv besser machen ... Aber die Jahre vergehen und die gesammelten Erfahrungen legen etwas anderes nahe. Unter dem Schnitt werde ich versuchen, kurz und vor allem in einfachen Worten zu erzählen, wie gut Architektur ist. Zumindest erweiterbar und unterstützt, für Details bitte ich um eine Katze…

Um eine gute Architektur des Projekts zu erstellen, müssen Sie sich zunächst für seine Funktionen entscheiden:

  1. Die Architektur muss unterstützt werden.
  2. Systemerweiterbarkeit ohne Krücken.
  3. Flexibilität der Einstellungen, viele Aufgaben müssen gelöst werden, ohne den Programmcode zu ändern.
  4. Zuverlässigkeit der Architektur.

Der erste Punkt ist, dass die einfache Unterstützung nach den Prinzipien von SOLID gelöst wird, im Grunde natürlich nach dem Prinzip der "Einzigartigkeit der Verantwortung". Sie müssen also eine Architektur wählen, die auf Microservices basiert, oder eine modulare Architektur eines monolithischen Kernsystems. Es gibt keinen grundsätzlichen Unterschied zwischen diesen Ansätzen. Für das Projekt, an dem ich arbeite, habe ich den zweiten Ansatz gewählt, Module.

Der zweite Punkt kann mithilfe des Programmiermusters für Ereignisbeobachter oder Dispatcher gelöst werden. Sie sind einander ähnlich, daher werden wir uns nicht darauf konzentrieren. Das Wesentliche ihrer Arbeit besteht darin, eine Nachricht aus dem Modul auszuführen, das gerade ausgeführt wird, und bei Bedarf das Modul anzuhören, das mit diesem Objekt arbeiten muss.

Der dritte Absatz wird ebenfalls ganz einfach gelöst, der beschreibende Teil der Entität, dh die Attribute der Entitäten, die getrennt von der Entität selbst gespeichert sind. Dies ist ein Verweis auf EAV (Entity Attribute Value). Sie müssen nicht alle Felder einer Entität für die Geschäftslogik verarbeiten, einige Attribute sind informativ geladen, andere werden zum Sortieren und Filtern verwendet und nur ein Teil zum Erstellen der Geschäftslogik. Wenn die Entität als EAV gespeichert ist, können wir daher jederzeit ein nicht benötigtes Attribut hinzufügen oder entfernen.

Der vierte Punkt unserer Anforderungen ist die Zuverlässigkeit, was ein Minimum an „Krücken“ und mehr Automatisierung bedeutet. Die meisten Webanwendungen bestehen aus Datenanzeigeschnittstellen, Tabellen, Filtern, Sortieren und Entitätskarten. Und Dateneingabeschnittstellen, Formulare. Daher lohnt es sich, Fabriken für Formulare, Fabriken für Tabellen, Fabriken für Karten zu verwenden. Mehr Automatisierung, am Ende können wir vom Bereich der Präsentation abstrahieren und uns auf Geschäftslogik und inhaltliche Aufgaben konzentrieren ...

Die Schlussfolgerung zeigt sich also, dass es zum Aufbau einer guten Architektur notwendig ist, zu abstrahieren, über Technologien und Programmiermuster zu entscheiden und eine Grundlage für den Beginn der Entwicklung zu schaffen ...

Jetzt haben wir einen Plan entwickelt, über die Anforderungen entschieden und müssen dann entscheiden, wie die Architektur erstellt werden soll. Tatsächlich verstehe ich nicht alle diese geschichteten Architekturen oder Zwiebeln. Ich habe ihnen etwas weggenommen und selbst etwas erfunden, und ich sehe nichts darin, wenn die Leute nur verstehen, was es bedeutet. Tatsächlich besteht die gesamte Architektur aus einfachen Schritten:

  • Die Grundlage ist die Abstraktion (abstrakte Klassen und Schnittstellen, die den Vertrag verschiedener Komponenten des Systems definieren, die zu Modulen zusammengefasst sind).
  • Als nächstes habe ich eine Kernel-Schicht, die die Module ausführt und verwaltet.
  • Laden des Layoutsystems
  • Nach dem Starten des Moduls wird jedes Modul als separater Microservice angeboten

Aber was macht Architektur gut? Die Frage ist nicht einfach, aber wenn alles auf die Ebene des philosophischen Denkens vereinfacht wird, wird diese Frage beantwortet. Nachdem die Anwendung gestartet wurde. Wir haben isolierte Teile, Module. Jedes Modul ist nur für eine Systemfunktionalität verantwortlich. Wir gehen jedes Modul durch, das als MVC-Anwendung konzipiert ist, und haben eine Ansicht, einen Controller und ein Modell. Und jeder Teil des Moduls ist auch für jede seiner Aktionen verantwortlich. Wir gehen noch tiefer und werden sehen, dass die Ansicht auch bestimmte Teile enthält, dies sind Factory-Klassen und Layout-Erweiterungen. In der Tat sind Layouts auch ein Modul, es wird zuerst geladen, alle anderen Module ergänzen es und bauen eine Schnittstelle (oder ein Ausgabesystem) auf. Aber wie macht man das alles weniger abhängig, fragt man? Und die Antwort wird für die Beobachter offensichtlich sein. Für jedes Rendern des Blocks des Layouts, das sie ihre Ereignisse auswerfen, müssen Sie nur dieses Ereignis anhören, Beobachter in Ihrer Anwendung, und die erforderliche Blockaktualisierung in den Ebenen hinzufügen und die entsprechende Ausgabe erhalten. Viele Module haben auch eigene Ereignisse, die andere Module abonnieren und in der Lage sind, Daten zum übertragenen Satz hinzuzufügen / oder zu aktualisieren. All dies führt dazu, dass in der Anwendung die Module wenig miteinander verbunden sind und ohne einander leben können.

In Anbetracht des oben Gesagten stellt sich eine vernünftige Frage: Wenn ein Modul ein anderes hört, ist es erforderlich, für diese Module eine Art Abhängigkeitsmanagementsystem zu haben. Das heißt, das Modul, von dem ein anderes Modul abhängt, müssen wir zuerst starten, und dasjenige, das abhängig ist, müssen wir nachlaufen. Und so entstand eine einfache Implementierung der Abhängigkeit. Wir erstellen eine Warteschlange zum Starten der Module und sortieren sie einfach so, dass die Module, von denen andere abhängen, zunächst geladen werden, natürlich nach dem Laden des Kernels.

Abschließend kann ich Folgendes sagen. Gute Architektur ist keine so schwierige und langfristige Aufgabe, sie einzusparen. Am Ende hilft es, Ressourcen und Zeit effizienter zu nutzen. Das Ändern der Einstellung im Bedienfeld dauert schließlich fünf Minuten. Zwei Zeilen zum Hinzufügen zu schreiben ist auch nicht so viel Zeit. Aber eine Schlussfolgerung zu ziehen, jeden einzelnen umzukehren und große Datenmengen zu debuggen, ist bereits eine Zeit, die um ein Vielfaches länger ist als die Zeit, um eine Architekturkonstruktionsstrategie zu entwickeln.

Source: https://habr.com/ru/post/de457422/


All Articles