Dies wird eine Geschichte über den Eindruck des Buches sowie einige Konzepte und Kenntnisse sein, die dank dieses Buches untersucht wurden
Architektur
Können Sie beim Lesen dieser Publikation eine klare Antwort auf die Frage geben, was Architektur ist? Was ist Architektur im Kontext von Programmierung und Design? Welche Rolle spielt sie? In diesem Begriff gibt es viele Unklarheiten. Und alles scheint klar zu sein, aber irgendwie abstrakt und ohne Genauigkeit. Martin glaubt und ich stimme ihm zu, dass die Anwendung zwei Komponenten hat:
- Verhalten (Verhalten) - Funktionen und Aufgaben, die das Programm (Komponente, Dienst) ausführt.
- Architektur - In diesem Begriff geht es mehr um das Ändern von Anwendungen.
Aber selbst wenn die Anwendung die Aufgabe, die sie ausführen sollte, sehr gut ausführt, bedeutet dies keineswegs, dass sie eine gute Architektur hat. Bei Architektur geht es nicht um Anwendungsverhalten. Bei Architektur geht es um einfache Änderungen, bei Architektur um einfache Bereitstellung, bei Architektur um Entwicklungsunabhängigkeit. Bei Architektur geht es um die Geschwindigkeit, mit der Verständnis zu einer neuen Person in einem Team gelangt
Und hier erfahren Sie, wie Sie diese Architektur erstellen, wie Sie Kopfschmerzen mit einer kleinen Änderung der Anforderungen von PM oder von einem Stakeholder loswerden: Dies wird in diesem Buch beschrieben
Über Autoren
Bevor ich etwas über dieses Buch sage, möchte ich ein wenig über mich selbst sagen.
Im Moment bin ich ein starker Junior-Entwickler, der sich auf die Entwicklung von Diensten über ASP .NET CORE spezialisiert hat.
Ich arbeite jetzt seit einem Jahr an einer "Galerie" und mache anscheinend ein wenig
Ich habe dieses Buch bereits 2 Mal gelesen und empfehle es jedem zu lesen:
- Entwickler eingebetteter Systeme;
- Front-Endchiker;
- Back Endors;
- und sogar Devopsam.
Im Allgemeinen, für jeden, der zumindest irgendwie mit der Entwicklung der PP verbunden ist, meine ich die direkte Entwicklung der verschiedenen Saylov und PM'ov hier, die wir hier nicht berücksichtigen (obwohl es auch nützlich wäre zu wissen, warum ein Dienstmädchen manchmal zweimal mehr Zeit für eine Aufgabe verbringt), rate ich Ihnen zu lesen dieses Buch.
Und jetzt werde ich versuchen zu argumentieren, warum ich das denke
Ein wenig über den Autor dieses Buches (weil für mich die Autorität des Schriftstellers eine große Rolle spielt). Ich denke, Sie werden mich verstehen, obwohl dies nicht immer richtig ist, aber wenn eine maßgebliche Person in der Sphäre etwas zu Ihnen sagt, zeigen Sie viel mehr Vertrauen in das, was sie gesagt hat. Ich denke zum Beispiel, Sie würden lieber an die Diagnose glauben, die der Arzt Ihnen stellt, als an eine Person aus der Menge (googeln Sie die Symptome).
Robert Martin - auch bekannt als Ankle Bob (Onkel Bob) - ist seit 1970 auf dem Gebiet der Programmierung und von verschiedenen Systemen (von Webdiensten bis zu eingebetteten Systemen) tätig. Er ist ein technischer Berater und Architekt, er schrieb in verschiedenen Fachzeitschriften, er ist ein sehr erfahrener Programmierer und eine Person, die eine der Schlüsselrollen bei der Erstellung der bekannten SOLID-Prinzipien spielte (man kann sagen der Schöpfer). Außerdem möchte ich hinzufügen, dass mein Teamleiter mit mehr als 15 Erfahrungen mich zu diesem Buch beraten hat
Über das Buch
Abhängigkeiten
Bevor ich das Buch las, las ich ziemlich viele Artikel über dasselbe Habré, in denen ein Wort wie „Abhängigkeit“ auftauchte. Was ist es, wer ist von wem abhängig, was genau bedeutet "abhängig von" und wie kann eine Klasse von jemandem abhängen?
Und als ich das Buch las, lernte ich zwei Punkte:
Abhängigkeit ist ein Begriff, der bedeutet, dass eine Klasse (Komponente, Dienst) eine andere Klasse (Komponente, Dienst) kennt, und dieses Wissen auf Codeebene wird durch einen bestimmten Namespace-Import bestimmt (jetzt verstehen mich Javisten, Scharfschützen, Sishniks) . Mit anderen Worten: Sie haben eine Klasse A mit einem Namespace Default.Classes und eine Klasse B Another.Classes. Wenn der Code der Klasse A mit Another.Classes angezeigt wird; - Dies bedeutet, dass Klasse A von Klasse B abhängt.
Um nach dem Schema zu verstehen, wo sich die abhängige Klasse befindet und wo nicht - schauen Sie in Pfeilrichtung: 1) Der Pfeil zeigt von Klasse A in Richtung Klasse B. Dies bedeutet, dass Klasse B unabhängiger ist als Klasse A. Und die Änderungen in Klasse A. , kein "Schaden" an Klasse B.
FEST
Einer der Hauptgründe für das Lesen dieses Buches war die Erklärung der SOLID-Prinzipien aus der Originalquelle, da Onkel Rob diese Prinzipien entwickelt hat und wir sagen können, dass wir dank ihm diesen Namen hören - SOLID.
Für diejenigen, die sich nicht auskennen - diese Grundsätze werden gesagt und empfohlen, ihre Anwendungen gemäß 5 Regeln zu gestalten:
S - SRP (Single Responsibility Prinzip)
O - OCP (Open-Closed-Prinzip)
L - LSP (Liskov-Substitutionsprinzip)
I - ISP (Prinzip der Schnittstellentrennung)
D - DIP (Abhängigkeitsinversionsprinzip)
Alle diese Prinzipien können auf der Ebene von Klassen und Objekten, auf der Ebene von Modulen und Komponenten und auf der Ebene von Schienen (Diensten) angewendet werden.
Wenn Sie der Meinung sind, dass das Prinzip der Einzelverantwortung darin besteht, dass die Klasse oder das Modul nur eines tun sollten, sollten Sie auf jeden Fall mindestens das Kapitel über Solid lesen. Denn die oben angegebene Definition ist eine Konsequenz, aber nicht die Definition des Prinzips selbst
Informationen zur Abhängigkeitsinversion
Ich möchte besonders auf die Erklärung des Abhängigkeitsinversionsprinzips (das, dass D von SOLID stammt) achten. Beim Lesen des Buches habe ich verstanden, dass dies 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 Details der Implementierung der Datenzugriffsschicht machen können (DAL'a)
Obwohl das Prinzip selbst zusammen mit den anderen in SOLID etwas anderes als den Mechanismus bedeutet, wird der Mechanismus selbst im gesamten Buch verwendet, und dies ist eine der Hauptmethoden zum Umkehren und Ändern der Richtung Ihrer Abhängigkeiten, die übrigens bei DDD verwendet wird
Über architektonische Entscheidungen
Sehr oft wird in dem Buch das Prinzip erwähnt, wichtige Architekturentscheidungen zu treffen: welche Datenbank verwendet werden soll, welches Framework verwendet werden soll, welche Bibliothek verbunden werden soll, was als Suchmaschine verwendet werden soll usw.
Der Autor glaubt also: Sie sollten diese Entscheidung so schnell wie möglich treffen. Da sich Anforderungen ändern können, aber auch Leistungsbeschränkungen, neigt die Verhaltenskomponente selbst dazu, sich zu ändern. Während des Entwicklungsprozesses scheint eine Lösung weniger effektiv als eine andere zu sein, weniger bequem als eine andere. Und die Stärke Ihrer Architektur bestimmt, wie schnell und schmerzlos Sie eine Technologie durch eine andere ersetzen können (OCP sagt dies übrigens).
Zum Beispiel entscheiden Sie sich plötzlich dafür, MongoDb anstelle von Postgresql oder Dateien im Allgemeinen zu verwenden oder verspottete Daten zu verwenden, deren Vorgänge im Speicher ausgeführt werden. Und unter bestimmten Umständen kann dies ermöglichen, fast die gesamte Logik neu zu schreiben.
Um solche Situationen zu verhindern, können wir einige Mechanismen verwenden, die die Entscheidungszeit so weit wie möglich verkürzen. Einer dieser Mechanismen ist die Abstraktion.
DDD-Referenzen
DDD - Domain Driven Design - ein Ansatz zur Entwicklung von Diensten mit komplexer Geschäftslogik, die für Änderungen von entscheidender Bedeutung ist und darauf abzielt, das Verständnis der Projektmanagementpositionen (PMs, Verkaufsmanager usw.) mit Ruderern zu maximieren. Das heißt, dass es eine allgegenwärtige Sprache zwischen allen Projektmitgliedern geben würde und jeder den anderen verstehen könnte und dass jeder in derselben Domäne mit denselben Geschäftsregeln denkt.
Wenn Sie ein Unterstützer von DDD sind oder einer sein möchten oder etwas darüber nicht verstehen, aber verstehen möchten, ist das Buch ein Muss, insbesondere der zweite Teil des Buches.
Hier erklärt der Autor die Existenz der Abhängigkeitsregel und warum Sie im Anschluss daran die richtige Anwendungsarchitektur erstellen. Warum Abhängigkeiten zu High Policy-Komponenten folgen sollten, warum die Domäne (High Policy-Komponente) unabhängig von der Infrastruktur sein sollte und wie dies die Bereitstellung und Entwicklung für Sie vereinfacht
Abstraktion
Onkel Rob spricht auch darüber, wie Implementierungsdetails Ihrem System schaden und verhindern können, dass es sich in Zukunft ohne Schmerzen weiterentwickelt.
Denken Sie daran!
DB ist ein Implementierungsdetail
Clients (Web, Mobile usw.) - Implementierungsdetails
Frameworks sind ein Implementierungsdetail.
Es ist notwendig, so viel wie möglich zu abstrahieren und nicht davon abhängig zu sein, indem die oben beschriebene Abhängigkeitsinversion mit Schnittstellen und Abstraktionen, Abhängigkeitsregeln und anderen Mechanismen verwendet wird
Methoden zum Erstellen von Modulen
Dieser Abschnitt hat mir als Serviceentwickler für ASP .NET CORE besonders gut gefallen. Denn es beschreibt die Methoden zum Aufbau einer einheitlichen Servicearchitektur aus vorgefertigten Komponenten.
Robert beschrieb 4 mögliche Schichttrennungsschemata.
Er machte deutlich, warum der so häufig verwendete Mechanismus der 3-Schicht-Architektur: Benutzeroberfläche (Controller), Dienste (Domäne), DAL (Datenbank) - im Vergleich zu anderen schlecht genug ist. Ich habe nicht viele Projekte gesehen, aber in jedem, zum Beispiel Micro-Service, wird im Back-End eine dreischichtige Architektur verwendet.
Außerdem wird häufig eine Ein-Komponenten-Ein-Service-Architektur verwendet. Im Allgemeinen sind beide gut, aber es hat viele Nachteile im Vergleich zum Beispiel, wie die Architektur mit DDD erstellt wird, insbesondere wenn sie für Änderungen kritisch ist, und komplexe Dienste.
Im Allgemeinen ist diese Rezension des Buches zu Ende gegangen. Das Buch selbst hat mir sehr gut gefallen, ich bereue nicht, was ich gelesen habe, dank des Autors. Vielen Dank für Ihre Aufmerksamkeit, liebe Leser, urteilen Sie nicht streng - diese Veröffentlichung basiert auf dem Eindruck des Buches und meiner persönlichen Begeisterung
UPDATE 1.0
Während der Diskussionen kann verstanden werden, dass die Änderung des Speichers SUDDEN und EASY auf die eine oder andere Weise nicht einfach sein wird. In einigen Fällen, selbst bei einer sehr schmerzhaften und dennoch abstrakten Abstraktion und Verkapselung des Zugangs zum Geschäft, ist es zweifelhaft, was die Situation verschlimmern wird, aber eher ein wenig besser, zumindest aufgrund der Unabhängigkeit der variablen Komponente von den anderen.