Dies wird eine ErzĂ€hlung ĂŒber die EindrĂŒcke von einem Buch sein, sowie einige Konzepte und Kenntnisse, die durch dieses Buch erworben wurden.
Architektur von
Können Sie, wÀhrend Sie diesen Beitrag lesen, eine klare Antwort auf die Frage geben: Was ist Architektur? Was bedeutet Architektur im Kontext von Programmierung und Design? Welche Rolle spielt sie? Es gibt viele Unklarheiten in diesem Begriff. Und obwohl alles klar zu sein scheint, bleibt es irgendwie abstrakt und ungenau. Martin ist der Meinung, und ich teile diese Ansicht, dass eine Anwendung zwei Komponenten hat:
- Verhalten (behavior) â die Funktionen und Aufgaben, die das Programm (Komponente, Dienst) ausfĂŒhrt.
- Architektur â dieser Begriff bezieht sich vielmehr auf die VerĂ€nderung der Anwendung.
Aber selbst wenn eine Anwendung ihre Aufgabe sehr gut erfĂŒllt, bedeutet das nicht, dass sie eine gute Architektur hat. Architektur handelt nicht vom Verhalten einer Anwendung. Architektur befasst sich mit der Ănderbarkeit, Architektur mit der Bereitstellung, Architektur mit der UnabhĂ€ngigkeit der Entwicklung. Architektur ist die Geschwindigkeit, mit der neues VerstĂ€ndnis zu einem neuen Mitglied im Team kommt.
Und so wird erklĂ€rt, wie man diese Architektur aufbaut und wie man Kopfschmerzen aufgrund kleiner Ănderungen der Anforderungen von PM oder Stakeholdern vermeidet: darum geht es in diesem Buch.
Ăber die Autoren
Bevor ich etwas ĂŒber dieses Buch sage, möchte ich kurz etwas ĂŒber mich erzĂ€hlen.
Ich bin derzeit ein Strong Junior Developer, der sich auf die Entwicklung von Services mit ASP .NET CORE spezialisiert.
Ich arbeite seit einem Jahr in einem âStartupâ und komme scheinbar ganz gut zurecht.
Ich habe dieses Buch bereits zweimal gelesen und empfehle es jedem:
- Entwicklern von Embedded-Systemen;
- Frontend-Entwicklern;
- Backend-Entwicklern;
- und sogar DevOps-Profis.
Kurz gesagt, jedem, der irgendwie mit der Softwareentwicklung zu tun hat, und zur direkten Softwareentwicklung, was Sales und PM nicht einschlieĂt (obwohl es auch nĂŒtzlich wĂ€re zu wissen, warum Entwickler manchmal doppelt so viel Zeit fĂŒr eine Aufgabe benötigen), empfehle ich, dieses Buch zu lesen.
Und jetzt werde ich versuchen zu argumentieren, warum ich das so sehe.
Ein wenig ĂŒber den Autor dieses Buches (denn die AutoritĂ€t des Schreibenden spielt fĂŒr mich eine groĂe Rolle). Ich denke, Sie werden mich verstehen; auch wenn das nicht immer richtig ist, zeigen wir oft mehr Vertrauen in die Aussagen einer autoritĂ€ren Person in ihrem Bereich. Zum Beispiel glauben wir eher einer Diagnose, die uns ein Arzt stellt, als einer Person aus der Menge, die die Symptome gegoogelt hat.
Robert C. Martin, auch bekannt als Uncle Bob (Onkel Bob), arbeitet seit 1970 im Bereich der Programmierung, einschlieĂlich verschiedener Systeme (von Webdiensten bis hin zu Embedded-Systemen). Er ist technischer Berater und Architekt, hat in verschiedenen Fachzeitschriften geschrieben und ist selbst ein sehr erfahrener Programmierer. Er hat eine SchlĂŒsselrolle bei der Entwicklung der bekannten SOLID-Prinzipien gespielt (man könnte sagen, er ist deren Schöpfer). AuĂerdem möchte ich erwĂ€hnen, dass mir dieses Buch von meinem Teamleiter mit ĂŒber 15 Jahren Erfahrung empfohlen wurde.
Ăber das Buch
AbhÀngigkeiten
Bevor ich das Buch las, hatte ich bereits viele Artikel auf demselben Medium gelesen, in denen das Wort âAbhĂ€ngigkeitâ vorkam. Was bedeutet das, wer ist von wem abhĂ€ngig, was bedeutet konkret âabhĂ€ngenâ, und wie kann eine Klasse von einer anderen abhĂ€ngen?
WĂ€hrend ich das Buch las, habe ich zwei Punkte verstanden:
AbhĂ€ngigkeit ist ein Begriff, der beschreibt, dass eine Klasse (Komponente, Dienst) ĂŒber eine andere Klasse (Komponente, Dienst) informiert ist, und dieses Wissen im Code durch einen bestimmten Namespace-Import definiert wird (jetzt wissen Java-Entwickler, C#-Entwickler und C-Entwickler, was ich meine). Anders ausgedrĂŒckt: Sie haben eine Klasse A mit dem Namespace Default.Classes und eine Klasse B mit Another.Classes. Wenn also im Quellcode von Klasse A steht using Another.Classes; â dann bedeutet das, dass Klasse A von Klasse B abhĂ€ngt.
Um auf der Grafik zu sehen, wo die abhĂ€ngige Klasse ist und wo nicht â beachten Sie 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. Und VerĂ€nderungen in Klasse A werden der 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 zu verdanken haben, dass wir diesen Namen â SOLID â hören.
FĂŒr diejenigen, die nicht im Bilde sind â diese Prinzipien sagen aus und empfehlen, Ihre Anwendungen nach 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 der Ebene von Klassen und Objekten, auf der Ebene von Modulen und Komponenten sowie auf der Ebene von Schichten (Services) angewendet werden.
Wenn Sie denken, dass das Single Responsibility Principle bedeutet, dass eine Klasse oder ein Modul nur eine einzige Aufgabe erledigen sollte, dann sollten Sie unbedingt zumindest das Kapitel ĂŒber SOLID lesen. Denn die oben gegebene Definition ist eine Folge, aber keineswegs die Definition des Prinzips.
Ăber Dependency Inversion
Besonderes Augenmerk möchte ich auf die ErklÀrung des Dependency Inversion Principle (das D aus SOLID) legen. WÀhrend des Lesens des Buches wurde mir klar, dass es sich hierbei nicht nur um ein Prinzip handelt, sondern auch um einen Mechanismus und ein Werkzeug, mit dem Sie die Richtung Ihrer AbhÀngigkeiten Àndern können, und beispielsweise die GeschÀftslogik (DOMAIN) unabhÀngig von den Implementierungsdetails der Data Access Layer (DAL) gestalten können.
Obwohl das Prinzip zusammen mit den anderen in SOLID steht, bedeutet es etwas anderes als der Mechanismus selbst, wird dieser Mechanismus durch das gesamte Buch hindurch verwendet und ist eine der Hauptmethoden, um Ihre AbhÀngigkeiten umzukehren und deren Richtung zu Àndern. Interessanterweise wird es auch im DDD verwendet.
Zur Entscheidung ĂŒber architektonische Lösungen
Sehr hĂ€ufig wird im Buch auf das Prinzip der Entscheidungsfindung ĂŒber wichtige architektonische Entscheidungen hingewiesen: welche Datenbank zu verwenden, welches Framework zu wĂ€hlen, welche Bibliothek einzubinden, welche Suchmaschine zu verwenden usw.
Der Autor ist der Auffassung, dass Sie solche Entscheidungen so wenig wie möglich treffen sollten. Denn Anforderungen können sich Ă€ndern, die LeistungsbeschrĂ€nkungen ebenfalls, und auch das Verhalten hat die Tendenz, sich zu wandeln. WĂ€hrend der Entwicklung kann sich eine Entscheidung als weniger effektiv oder weniger komfortabel im Vergleich zu einer anderen erweisen. Die StĂ€rke Ihrer Architektur bestimmt, wie schnell und schmerzfrei Sie eine Technologie durch eine andere ersetzen können (darĂŒber spricht ĂŒbrigens auch das OCP).
Beispielsweise entscheiden Sie plötzlich, statt PostgreSQL MongoDB zu nutzen, oder sogar Dateien oder Mock-Daten zu verwenden, mit denen Operationen im Speicher durchgefĂŒhrt werden. Unter bestimmten Bedingungen könnte dies dazu fĂŒhren, dass fast die gesamte Logik neu geschrieben werden muss.
Um solche Situationen zu vermeiden, können wir einige Mechanismen einsetzen, die den Zeitpunkt der Entscheidungsfindung so weit wie möglich hinauszögern. Einer dieser Mechanismen ist die Abstraktion.
Verweise auf DDD
DDD â Domain Driven Design â ein Ansatz zur Entwicklung von Services mit komplexer GeschĂ€ftslogik, die kritisch auf VerĂ€nderungen reagieren muss. Dieser Ansatz zielt darauf ab, ein maximales VerstĂ€ndnis zwischen den verantwortlichen Personen im Projekt (Projektmanager, Vertriebsleiter usw.) und den Teammitgliedern zu erreichen. Das bedeutet, dass alle Projektbeteiligten eine gemeinsame Sprache verwenden, um sich gegenseitig zu verstehen, und dass jeder im selben Fachbereich mit denselben GeschĂ€ftsregeln denkt.
Wenn Sie ein BefĂŒrworter von DDD sind, oder sein möchten, oder wenn Sie etwas darĂŒber erfahren möchten, aber noch unsicher sind â dieses Buch ist ein Muss, insbesondere der zweite Teil.
Hier erklÀrt der Autor das Prinzip der Dependency Rule und warum Sie, wenn Sie ihm folgen, die richtige Architektur Ihrer Anwendung aufbauen werden. Warum AbhÀngigkeiten in Richtung der High Policy-Komponenten gerichtet sein sollten, und warum Hosting (High Policy-Komponenten) unabhÀngig von der Infrastruktur sein sollten und wie dies Ihre Deployment- und Entwicklungsprozesse vereinfachen kann.
Abstraktion
Onkel Rob erklÀrt auch, wie die Implementierungsdetails Ihrer Systemarchitektur schaden können und die Weiterentwicklung ohne Schwierigkeiten behindern könnten.
Denken Sie daran!
Die Datenbank ist ein Implementierungsdetail.
Kunden (Web, Mobile usw.) sind ebenfalls Details der Implementierung.
Frameworks sind ein Implementierungsdetail.
Es ist wichtig, sich davon so weit wie möglich zu abstrahieren und nicht abhÀngig zu sein, indem man das oben beschriebene Dependency Inversion mit Schnittstellen und Abstraktionen sowie die Dependency Rule und andere Mechanismen anwendet.
Methoden zur Modularisierung
Dieser Abschnitt hat mir besonders gut gefallen, da ich Dienste auf ASP .NET CORE entwickle. Hier werden Methoden zur Erstellung einer einheitlichen Architektur aus fertigen Komponenten beschrieben.
Robert hat vier mögliche Schemas zur Trennung von Schichten beschrieben.
Er hat erklÀrt, warum der so hÀufig verwendete Mechanismus der 3-Schichten-Architektur: UI (Controller), Services (Domain), DAL (Datenbank) im Vergleich zu anderen ziemlich schlecht ist. Ich habe nicht viele Projekte gesehen, aber in jedem, z. B. in Mikrodiensten, wird genau diese dreischichtige Architektur im Backend verwendet.
Auch die Architektur eines Komponenten-ein-Dienstes wird hĂ€ufig verwendet. Insgesamt sind beide AnsĂ€tze nicht schlecht, jedoch haben sie im Vergleich zu der Architektur, die beispielsweise beim Einsatz von DDD, insbesondere bei kritischen Ănderungen und komplexen Diensten, viele Nachteile.
Insgesamt ist dies das Ende meiner Rezension des Buches. Mir hat das Buch sehr gut gefallen, und ich bereue das Lesen nicht. Vielen Dank an den Autor. Und Ihnen, liebe Leser, danke fĂŒr Ihre Aufmerksamkeit. Urteilt nicht zu streng â diese Veröffentlichung basiert auf meinen EindrĂŒcken aus dem Buch und meinem persönlichen Enthusiasmus.
Quelle: habr.com
