Kurz und bündig: Clean Architecture, Robert C. Martin

Dies wird eine Erzählung über den Eindruck von dem Buch sein, sowie werden einige Konzepte und Kenntnisse betrachtet, die dank dieses Buches erlernt wurden.

Architektur

Können Sie, während Sie diese Veröffentlichung lesen, eine klare Antwort auf die Frage geben, was Architektur ist? Was ist Architektur im Kontext von Programmierung und Design? Welche Rolle spielt sie? Es gibt genug Unklarheiten in diesem Begriff. Es scheint klar zu sein, aber irgendwie abstrakt und ohne Genauigkeit. Martin ist der Meinung, und ich stimme ihm zu, dass eine Anwendung zwei Komponenten hat:

1. Verhalten (behavior) – die Funktionen und Aufgaben, die das Programm (Komponente, Dienst) ausführt.
2. Architektur – dieser Begriff handelt hauptsächlich von der Veränderung der Anwendung.

Aber selbst wenn eine Anwendung die Aufgabe, die sie erfüllen soll, sehr gut erfüllt, bedeutet das noch lange nicht, dass sie eine gute Architektur hat. Architektur handelt nicht vom Verhalten der Anwendung. Architektur handelt von der Leichtigkeit der Veränderbarkeit, Architektur handelt von der Leichtigkeit der Bereitstellung, Architektur handelt von der Unabhängigkeit der Entwicklung. Architektur handelt von der Geschwindigkeit, mit der neues Verständnis zu einer neuen Person im Team kommt.

Und wie man diese Architektur aufbaut, wie man sich von Kopfschmerzen bei kleinen Änderungen von Anforderungen des PM oder des Stakeholders befreit: darüber wird das Buch berichten.

Über die Autoren

Bevor ich etwas über dieses Buch sage, möchte ich ein wenig über mich selbst erzählen.
Zurzeit bin ich ein starker Junior-Entwickler, der sich auf die Entwicklung von Diensten mit ASP .NET CORE spezialisiert hat.

Ich arbeite seit einem Jahr in einer „Galerie“ und scheine mich langsam ein wenig zu bewähren.

Ich habe dieses Buch bereits zweimal gelesen und empfehle es allen:

• Entwicklern von eingebetteten Systemen;
• Frontend-Entwicklern;
• Backend-Entwicklern;
• und sogar DevOps.

Im Allgemeinen allen, die irgendwie mit Softwareentwicklung verbunden sind, d.h. die direkte Entwicklung von verschiedenen Softwarelösungen umfasst, PMs und Sales zählen hier nicht dazu (obwohl es auch nützlich wäre zu wissen, warum Entwickler manchmal doppelt so viel Zeit für eine Aufgabe benötigen), ich empfehle, dieses Buch zu lesen.
Und jetzt werde ich versuchen zu argumentieren, warum ich so denke.

Ein wenig über den Autor dieses Buches (weil für mich die Autorität des Schreibenden eine große Rolle spielt). Ich denke, Sie werden mich verstehen, auch wenn das nicht immer richtig ist, aber wenn Ihnen eine autoritative Person auf einem Gebiet etwas sagt - zeigen Sie viel mehr Vertrauen in das Gesagte. Zum Beispiel denke ich, dass Sie dem Urteil eines Arztes über eine Diagnose eher Glauben schenken als dem eines Menschen aus der Menge (der Symptome gegoogelt hat).

Robert Martin - auch bekannt als Uncle Bob - arbeitet seit 1970 im Bereich Programmierung, und zwar in verschiedenen Systemen (von Webservices bis Embedded Systems). Er ist technischer Berater und Architekt, hat für verschiedene technische Zeitschriften geschrieben, ist ein sehr erfahrener Programmierer und ein Mensch, der eine der Schlüsselrollen bei der Entwicklung der allseits bekannten SOLID-Prinzipien gespielt hat (man kann sagen, er ist der Schöpfer). Ich möchte auch hinzufügen, dass mir dieses Buch von meinem Teamleiter mit über 15 Jahren Berufserfahrung empfohlen wurde.

Über das Buch

Abhängigkeiten

Vor der Lektüre des Buches habe ich viele Artikel auf Habré gelesen, in denen das Wort "Abhängigkeit" vorkam. Was ist das, wer hängt von wem ab, was bedeutet "abhängen", und wie kann eine Klasse von einer anderen abhängen?

Und während ich das Buch las, habe ich zwei Punkte verstanden:

Eine Abhängigkeit ist ein Begriff, der bedeutet, dass eine Klasse (Komponente, Dienst) über eine andere Klasse (Komponente, Dienst) Bescheid weiß, und dieses Wissen wird auf Code-Ebene festgestellt (jetzt werden Java-Entwickler, C#-Entwickler und C-Entwickler mich verstehen) durch einen bestimmten Import des Namensraums. Mit anderen Worten: Wenn Sie eine Klasse A mit dem Namensraum Default.Classes und Klasse B mit Another.Classes haben. Wenn der Quellcode von Klasse A die Zeile using Another.Classes; enthält, bedeutet das, dass Klasse A von Klasse B abhängt.
Um im Diagramm zu erkennen, wo die abhängige Klasse ist und wo nicht - achten Sie auf die Richtung des Pfeils: In 1) zeigt der Pfeil von Klasse A in Richtung Klasse B. Das bedeutet, dass Klasse B unabhängiger ist als Klasse A. Änderungen in Klasse A werden Klasse B keinen "Schaden" zufügen.

SOLID

Einer der Hauptgründe, warum ich dieses Buch gelesen habe, ist die Erklärung der SOLID-Prinzipien aus erster Hand, denn Onkel Bob hat diese Prinzipien entwickelt, und man kann sagen, dass wir ihm verdanken, dass wir diesen Namen - SOLID - hören.
Für diejenigen, die nicht im Bilde sind – diese Prinzipien besagen und empfehlen, Ihre Anwendungen gemäß 5 Regeln zu gestalten:

S – SRP (Single Responsibility Principle)
O – OCP (Open-Closed Principle)
L – LSP (Liskov Substitution Principle)
I – ISP (Interface Segregation Principle)
D – DIP (Dependency Inversion Principle)

Alle diese Prinzipien können auf Klassen- und Objektlevel, auf Module und Komponenten sowie auf Ebenen (Services) angewendet werden.

Wenn Sie der Meinung sind, dass das Single Responsibility Principle besagt, dass eine Klasse oder ein Modul nur eine Aufgabe erfüllen sollte – dann müssen Sie unbedingt mindestens das Kapitel über SOLID lesen. Denn die obige Definition ist nur eine Konsequenz und kein tatsächliches Definition des Prinzips.

Über Dependency Inversion

Besonders erwähnenswert ist die Erklärung des Dependency Inversion Principle (das 'D' aus SOLID). Während ich das Buch las, wurde mir klar, dass es nicht nur ein Prinzip ist, sondern auch ein Mechanismus und ein Werkzeug, mit dem Sie die Richtung Ihrer Abhängigkeiten ändern und beispielsweise die Geschäftslogik (DOMAIN) unabhängig von den Implementierungsdetails der Datenzugriffsschicht (DAL) machen können.

Obwohl das Prinzip neben den anderen in SOLID nicht ganz das Gleiche wie der Mechanismus bedeutet, wird der Mechanismus während des gesamten Buches verwendet und ist eine der grundlegenden Methoden, um die Richtung Ihrer Abhängigkeiten umzudrehen und zu ändern, die übrigens bei DDD verwendet wird.

Über die Annahme architektonischer Entscheidungen

Sehr oft wird im Buch auf das Prinzip der Annahme wichtiger architektonischer Entscheidungen hingewiesen: Welche Datenbank zu verwenden, welches Framework zu nutzen, welche Bibliothek zu integrieren, welchen Suchalgorithmus zu verwenden usw.

Der Autor ist der Meinung: Sie sollten solche Entscheidungen SO WENIG WIE MÖGLICH treffen. Denn die Anforderungen können sich ändern, auch die Einschränkungen hinsichtlich der Leistung; das Verhalten unterliegt ebenfalls Änderungen. Im Verlauf der Entwicklung kann sich eine Lösung als weniger effektiv oder weniger komfortabel herausstellen als eine andere. Die Stärke Ihrer Architektur wird bestimmen, wie schnell und schmerzlos Sie eine Technologie durch eine andere ersetzen können (darauf besteht übrigens OCP).

Zum Beispiel entscheiden Sie sich plötzlich, anstelle von PostgreSQL MongoDB zu verwenden, oder sogar Dateien, oder Sie nutzen gemockte Daten, mit denen Operationen im Speicher durchgeführt werden. Und unter bestimmten Umständen kann dies dazu führen, dass beinahe die gesamte Logik neu geschrieben werden muss.

Um solche Situationen zu vermeiden, können wir einige Mechanismen verwenden, die den Zeitpunkt der Entscheidungsfindung so weit wie möglich hinauszögern. Ein solcher Mechanismus ist die Abstraktion.

Verweise auf DDD

DDD — Domain Driven Design — ist ein Ansatz zur Entwicklung von Dienstleistungen mit komplexer Geschäftslogik, die kritisch auf Änderungen reagiert. Dieser Ansatz zielt darauf ab, das Verständnis der Projektleiter (PMs, Vertriebsleiter usw.) sowie der Teammitglieder zu maximieren. Das bedeutet, dass alle Projektmitglieder eine gemeinsame Sprache sprechen sollten und jeder den anderen verstehen kann, sodass alle im selben Fachgebiet mit denselben Geschäftsregeln denken.

Wenn Sie ein Anhänger von DDD sind, oder es werden möchten, oder wenn Sie etwas davon nicht verstehen, aber mehr wissen möchten — ist das Buch eine Pflichtlektüre, insbesondere der zweite Teil des Buches.

Hier erklärt der Autor das Konzept der Dependency Rule und warum Sie, wenn Sie ihm folgen, eine richtige Anwendungsarchitektur entwickeln werden. Warum Abhängigkeiten in Richtung der Komponenten mit hoher Politik folgen sollten, warum Domain haben (Komponente mit hoher Politik) unabhängig von der Infrastruktur sein sollte und wie das Ihnen bei Deployment und Entwicklung helfen wird.

Abstrahierung

Onkel Rob erzählt auch, wie die Details der Implementierung Ihrer System schaden können, und es Ihnen in Zukunft schwer machen, ohne Schmerzen zu evolvieren.

Denken Sie daran!
Die Datenbank ist ein Detail der Implementierung.
Die Clients (Web, Mobile usw.) sind Details der Implementierung.
Frameworks sind ein Detail der Implementierung.

Von all dem sollte man sich so weit wie möglich abstrahieren und nicht davon abhängen, indem man die oben beschriebene Dependency Inversion mit Schnittstellen und Abstraktionen, die Dependency Rule und andere Mechanismen verwendet.

Methoden zum Aufbau von Modulen

Dieser Abschnitt hat mir besonders gut gefallen, als Entwickler von Diensten auf ASP .NET CORE. Denn hier werden die Methoden zur Schaffung einer einheitlichen Architektur des Dienstes aus fertigen Komponenten beschrieben.

Robert beschreibt 4 mögliche Modelle zur Schichtung.

Er machte deutlich, warum der so häufig verwendete Mechanismus der 3-Schichten-Architektur: UI (Controller), Dienste (Domain), DAL (Datenbank) — im Vergleich zu anderen ziemlich schlecht ist. Ich habe nicht viele Projekte gesehen, aber in jedem, zum Beispiel in Mikrodiensten, wird genau diese Drei-Schichten-Architektur im Backend verwendet.

Ebenfalls wird häufig die Architektur ein-Komponente-ein-Dienst verwendet. Insgesamt sind beide nicht schlecht, aber sie hat im Vergleich, zum Beispiel, zur Architektur, die bei der Verwendung von DDD aufgebaut wird, besonders bei kritischen Änderungen und komplexen Diensten, einige Nachteile.

Nun, damit ist diese Rezension über das Buch zu Ende. Mir hat das Buch sehr gut gefallen, ich bereue das Gelesene nicht, danke an den Autor. Ihnen, liebe Leser, danke für Ihre Aufmerksamkeit, urteilen Sie nicht zu streng – diese Veröffentlichung basiert auf den Eindrücken vom Buch und meinem persönlichen Enthusiasmus.

Quelle: habr.com