Saubere Architektur
Clean ArchitectureVon Robert C. Martin
Rezensionen: 30 | Gesamtbewertung: Durchschnitt
| Ausgezeichnet | |
| Gut | |
| Durchschnitt | |
| Schlecht | |
| Schrecklich |
Aufbauend auf dem Erfolg der Bestseller The Clean Coder und Clean Code zeigt der legendäre Software-Handwerker Robert C. "Onkel Bob" Martin, wie man der Anwendungsarchitektur und dem Anwendungsdesign mehr Professionalität und Disziplin verleiht. Wie bei seinen anderen Büchern funktioniert auch Martins Clean Architecture nicht Präsentieren Sie nicht nur mehrere Auswahlmöglichkeiten und Optionen und sagen Sie "Verwenden Sie Ihr bestes Urteilsvermögen": es
Es ist so, aber meistens nicht ganz so. Wirklich, dieses Buch enthält viele Hintergrundinformationen, um das "Fleisch" des Buches zu verstehen, und das Fleisch des Buches ist Martin, der sein Clean Architecture-Muster vorstellt, das er 2012 vorgeschlagen hat und auf dem er viel präsentiert und trainiert hat: https://8thlight.com/blog/uncle-bob/2...
Auf diese Weise fühlt sich dieses Buch viel spezifischer an als Clean Code oder The Clean Coder. Während diese beiden Bücher allgemeine Ratschläge für Softwareprofis sind, handelt es sich eher um ein erweitertes Entwurfsmusterbuch, das nur ein einzelnes Muster abdeckt. Es wird als der einzig richtige Weg präsentiert, und obwohl ich persönlich Martins Perspektive und seiner Abneigung gegen rahmenlastige Architekturen zustimme, war es ein bisschen enttäuschend, dass das Buch vor fünf Jahren größtenteils ein sehr tiefer Sprung in einen Blog-Beitrag war.
Das "Aufbau" Zeug ist eigentlich interessanter. Es geht darum, SOLID-Prinzipien auf Architektur anzuwenden, und ich habe diesen Abschnitt des Buches wirklich genossen. Ich hatte das Gefühl, dass ich die Abhängigkeitsinversion auf Komponentenebene endlich durchgeknallt habe, und es gibt viel, was ich auf Architekturprobleme anwenden kann. Dieser Abschnitt des Buches fühlt sich sehr allgemein an, obwohl es, wie die meisten Arbeiten von Martin, eine weitere Wiederholung von SOLID ist und über FitNesse spricht, zwei Dinge, die er erstaunlich weit gebracht hat, bis zu einem Punkt, an dem man sich wundert, ob er jemals etwas getan hat sonst (er hat, aber Junge, er kehrt viel zu diesen Brunnen zurück).
In gewisser Weise sind dies zwei kürzere Bücher, die zusammengeschlagen wurden. Eines davon ist Clean Architecture, ein Buch über das Erstellen sauberer Architektur nach SOLID-Prinzipien (und einige neue). Das andere ist ein Buch über das Clean Architecture Pattern, eine besondere Methode zur Architektur von Systemen, die viel mit dem hexagonalen Architekturmuster von Allistair Cockburn zu tun hat. Diese beiden Konzepte verwenden genau den gleichen Namen, um, glaube ich, die Leser absichtlich dazu zu bringen, die beiden Konzepte als eins zusammenzuführen und das Gefühl zu verlieren, dass Martins Vorschlag der einzig mögliche Weg ist, ein System auf eine saubere Weise zu entwerfen. Aber eines dieser Dinge ist "saubere Architektur" und das andere ist "saubere Architektur", und es ist oft schwer zu erkennen, was was ist. Das ist beabsichtigt, denke ich.
Auf jeden Fall ist das Buch wirklich gut und ich habe viel davon mitbekommen, obwohl es nicht das war, was ich wirklich erwartet hatte. Die erste Hälfte (oder so) des Buches fühlt sich an wie 80% Wiederholung von Sachen, die ich zuvor von Martin gesehen habe, mit 20% extrem guten und nützlichen neuen Sachen. Dann ist die zweite Hälfte des Buches ein völlig anderes Thema, das als dasselbe Thema präsentiert wird, was mir Spaß gemacht hat, aber ich kann sehen, dass viele Leser von abgeschaltet werden. Ich würde das Buch immer noch empfehlen und ich denke, es lohnt sich für jeden, der der Meinung ist, dass "Architektur" Teil seiner Arbeit ist.
Über dieses Buch hatte ich möglicherweise zu hohe Erwartungen an dieses Buch. Ich bin enttäuscht. 85% des Buches befasst sich mit den SOLID-Prinzipien und deren Anwendung auf Komponenten (dies wird bereits in seinen Videos und meiner Meinung nach ausführlicher erläutert). Die anderen 15% des Buches handeln von seiner Präsentation „Architektur, die verlorenen Jahre“, in der er über die Architektur von Grenzinteraktoren und Entitäten spricht. Diese Architektur ähnelt der hexagonalen Architektur (Ports und Adapter), Zwiebeln usw.
Im gesamten Buch werden nicht mehr als 50 Codezeilen angezeigt. Die Konzepte der BIE-Architektur werden grob erklärt. Es gibt fast keine Verweise auf Nachrichten oder Ereignisse. Microservices oder serviceorientierte Architektur werden erwähnt, Erklärungen sind jedoch nicht zufriedenstellend. Greg Young wird auf der Dankesseite angezeigt, es wird jedoch kein CQRS oder Event Sourcing erwähnt.
Herr Martin, ich liebe Ihre Arbeit, aber dieses Buch ist nicht so gut wie die anderen. Vielen Dank!
Um die in diesem Buch erwähnten Modularitätsmuster zu verstehen, schlage ich vor, einen alternativen Weg einzuschlagen - das Lesen von "Java Application Architecture" von Kirk Knoernschild.
Neben Modularität und SOLID versucht das Buch, die hexagonale Architektur (a-ka Clean Architecture) zu erklären. Google es einfach, um die Idee zu erfassen und dann "Java Application Architecture" zu lesen.
Die im Buch erwähnten Ideen haben praktische Anwendung und sind in einigen Zusammenhängen von Vorteil. Das Problem ist, dass der Kontext nicht festgelegt ist und die Nachteile nicht richtig untersucht wurden. Dem Buch fehlen auch praktische Beispiele (die Fallstudie umfasst nur 2 Seiten).
Es gibt jedoch ein Kapitel, das mir gefällt - es ist ein Kapitel von Simon Brown (auf Verpackung). Um die Idee zu verstehen, können Sie Simons Blog-Beitrag "Ein architektonisch offensichtlicher Codierungsstil" lesen. Außerdem hat Simon ein großartiges Buch geschrieben - "Software Architecture for Developers".
Das Beste daran ist natürlich, dass es jetzt eine Armee von Bro-Codierern gibt, die glauben, dass sie wissen, was los ist. Jedes einzelne Code-Paket, das sie einchecken, verfügt über eine nutzlose Schnittstelle für jede "Implementierungs" -Klasse.
Hier ist ein Tipp für das Leben: Wenn Sie jemals auf zwei Dateien stoßen, von denen eine eine Schnittstelle mit dem Namen OrderService und eine andere eine Implementierung dieser Schnittstelle ist, die mit -Impl endet, wie OrderServiceImpl, tun Sie bitte allen einen Gefallen und führen Sie sie einfach zusammen die Zwei. Die einzige Tatsache, dass jemand dem Klassennamen -Impl hinzufügen musste, bedeutet, dass es nie eine zweite Implementierung geben wird, sodass die von ihnen definierte Schnittstelle nutzlos ist und ins Leere gelöscht werden muss. Es ist nur Müllcode, der die Projektstruktur überfüllt. Vielleicht, nur vielleicht, wenn wir alle dieser Regel folgen, wird sich irgendwann der gesunde Menschenverstand durchsetzen. Bis dahin hilft Gott uns allen.
1. Auch wenn es (irgendwann) täuschend einfach aussieht, ... ist es nicht. Tatsächlich sind die wertvollsten Lektionen nur für Personen mit einem bestimmten Erfahrungsniveau wirklich verständlich (und klar).
2. Dieses Buch versucht nicht, etwas End-to-End zu behandeln, sondern befasst sich eher mit bestimmten Aspekten der Softwarearchitektur, die Onkel Bob am wichtigsten findet (z. B. SOLID-Prinzipien, Grenzen, richtige Herangehensweise an die Komposition usw.). . Unnötig zu erwähnen, dass diese universell und technologieunabhängig sind (was gut ist), aber sie sind am besten für typische OO-Sprachen und -Plattformen geeignet.
3. Der Anhang (der ~ 20% -25% des Buches ausmacht) ist sehr persönlich, ziemlich beeindruckend, aber ... nicht wirklich unterhaltsam oder lehrreich. Aber gut, es ist Onkel Bob, also können solche Dinge vergeben werden;)
Ist es ein gutes, wertvolles Buch für einen aufstrebenden oder sogar erfahrenen Architekten? Ich denke schon - ich mag es, wenn man sich auf Prinzipien anstatt auf Muster konzentriert und ich persönlich denke, das ist etwas, woran wir wirklich erinnert werden müssen.
Wenn es bei sauberem Code nur um den Code ging, geht es darum, wie Sie den Code strukturieren, um ihn wiederverwendbarer, Framewoderk-unabhängiger und solider zu machen.
Wenn Sie der Meinung sind, dass MVC und Rails oder Django oder Phoenix der richtige Weg für ein Webprojekt sind, denken Sie mit diesem Buch noch einmal darüber nach.
Gute Software basiert nicht auf einem Framework. Es verwendet das Framework nur dann, wenn es benötigt wird.
Das Buch behandelt verschiedene Seiten der Rolle des Software-Architekten. Die widersprüchliche Zusammenarbeit von Wirtschaft und Technologie. Die Schwerpunktthemen des Architekten. Die Architekturprinzipien leiten sich von den berühmten SOLID-Prinzipien ab und haben sich durch Jahrzehnte bewährt. Einige der häufigsten Architekturfehler.
Alle Themen des Buches haben helle und lakonische Beschreibungen. Es gibt auch viele farbenfrohe und didaktische Beispiele für die Ideen, die oft aus der Erfahrung des Autors stammen. Außerdem gibt es ein ganzes Anhangskapitel voller autobiografischer Geschichten.
Ich finde dieses Buch großartig, wenn es darum geht, die Essenz der Rolle des Architekten und die Grundprinzipien, denen man folgen sollte, vorzustellen.
In Bezug auf dieses Buch hatte ich das Gefühl, immer wieder dasselbe zu lesen. Es ging darum, Schnittstellen zu verwenden und Ihre Geschäftslogik und Implementierungsdetails zu verbergen. Es geht darum, die SOLID-Prinzipien in das Design Ihrer Architektur einzubeziehen. Es geht um die Verwendung von Komponenten. Auch die Microservices- und SOA-Architekturen wurden erwähnt, aber die Erklärungen gefielen mir nicht. Es gab nichts über Nachrichten und Ereignisse.
Insgesamt empfehle ich dieses Buch nicht. Es ist besser, die anderen Bücher von Onkel Bob zu lesen, aber dieses ist es meiner Meinung nach nicht wert.
Das Buch ist auch nur wegen des Stils und der Geschichte eine gute Lektüre. Onkel Bob ist immer ein guter Geschichtenerzähler.
Lies einfach und genieße das Buch. Erwarten Sie nicht, dass es einen neuen Architekturstil beschreibt. Lesen Sie es als Roman.
Ich würde das Buch in zwei Hälften teilen. Die erste davon ist kaum relevant - es sind meistens Anekdoten und Dinge, die (meiner Meinung nach) nicht unbedingt in einem Buch über Architektur enthalten sein müssen, insbesondere wenn Sie bereits Kenntnisse über Designmuster haben. (Im Ernst, warum sollte man sich die Mühe machen, strukturierte, objektorientierte und funktionale Programmierung zu erklären?) In der zweiten Hälfte würde man den fleischigen Inhalt erwarten, aber am Ende des Tages kann das meiste davon nicht in einem einfachen Satz zusammengefasst werden : keine Kopplung machen. Führen Sie keine Kopplung in Ihrer Datenbank durch, keine Kopplung in Ihren Diensten, keine Kopplung in Ihrem Web-Frontend ... und ein Kapitel für jeden einzelnen Ort, an dem Sie eine Kopplung vermeiden möchten.
Um fair zu sein, es gibt ein paar Juwelen und nützliche Informationen, die über das Buch verstreut sind, aber selbst in diesen Fällen waren viele von ihnen untererklärt. Unwichtigen Themen wird zu viel Aufmerksamkeit geschenkt, den Punkten, die ich am relevantesten fand, zu wenig.
Es ist ziemlich traurig, dass das einzige Kapitel, das ich von Anfang bis Ende nützlich fand, "The Missing Chapter" heißt. Vielleicht weist der Name darauf hin, wie schwierig es ist, ein einzelnes nützliches Kapitel in ein ansonsten meist sinnloses Buch einzubauen.
Alle im Buch beschriebenen Prinzipien sind sinnvoll, wenn Sie sie verstanden und Probleme in der Praxis gesehen haben. Aber was ist, wenn Sie mit ihnen nicht vertraut sind? Was ist, wenn Sie sie verstehen wollen? In diesem Fall würde das Buch nicht helfen: Das Kapitel über Design- / Architekturprinzipien ist ohne praktische Beispiele sehr kurz.
Das Fehlen von Beispielen ist jedoch das Hauptproblem. Es ist schwierig, gute Beispiele für ein Design- / Architekturbuch bereitzustellen, aber ohne sie ist es schwierig, das Wissen auf Ihre Projekte zu übertragen. Der Autor liefert einige Beispiele mit einer sehr allgemeinen Beschreibung, die jedoch nicht sehr nützlich sind.
Es ist eine gute Lektüre, aber nur, wenn Sie alles wissen und sich nur an Design- / Architekturprinzipien erinnern möchten. Aber wenn Sie etwas lernen wollen, denke ich nicht, dass das Buch Ihnen eine umsetzbare Anleitung für Sie geben wird.
Es würde nicht viele Menschen geben, die viel davon profitieren würden. Anfänger würden viel mehr Kontext und Beispiele benötigen, während erfahrene Entwickler nicht viel Neues lernen würden. Das Mischen von Prinzipien mit einer spezifischeren vorgeschlagenen Architektur hilft auch nicht.
Saubere Architektur ist nützlich, um ein Gespräch zu beginnen, Fragen zu stellen oder Ideen zu geben, wie man Muster erklärt, die man auf unbewusster Ebene versteht.
- Achten Sie darauf, wie Sie Ihren Unit-Test erstellen.
- Anwenden von SOLID-Prinzipien in einer Webdienstarchitektur
- Ein monolithischer Architekt ist nicht schlecht, wenn Sie die Vor- und Nachteile kennen
- Verwenden Sie Framework, aber nicht Ihre Geschäftslogik mit ihnen verheiratet
====================
Nicht auf der Ebene von Clean Code und Clean Coder.
Dieses Buch ist viel gepolstert und wiederholt, es endet weniger oder mehr bei 60/65%, der Rest ist ein Anhang über ein sehr altes Projekt mit sehr alter Technologie, in dem RC Martin gearbeitet hat, und spricht über die Architektur, die auf einem sehr sehr hohen Niveau verwendet wurde.
Ein großer Teil des Buches wiederholte das Konzept der vom Geschäftszugriff getrennten Geschäftsregel und der von der Benutzeroberfläche getrennten Geschäftsregel.
Natürlich ist es richtig, aber einmal ist genug, wenn man bedenkt, dass diese Schichtentrennung meiner Meinung nach auch bei Projekten mit geringerer Qualität im professionellen Umfeld, die ich je gesehen habe, nie verpasst wird.
Es gab einige neue gute Punkte wie Metriken zur Berechnung der Kopplung zwischen Komponenten und einige Hinweise, wie man zu einer schreienden Architektur übergeht, die nach einem "Packaging by Feature" - oder "Packaging by Component" -Ansatz anstelle eines "Packaging by Layer" -Ansatzes strukturiert ist .
Aber dieser Punkt ist nicht so detailliert, weniger "BL von Dal trennen" und mehr Beispiele für die Verpackung nach Komponentenbeispielen wären besser gewesen.
Clean Series Review
===============
In Anbetracht aller drei Bücher der Cean-Reihe konzentriert sich C.Marting meiner Meinung nach hauptsächlich auf die Produktentwicklung.
Ich denke, dass dieser hohe Qualitätsstandard von extremer Abstraktion, extremer Entkopplung, sogar extremer Entkopplung vom Framework, extremer TDD und extremem Refactoring Sinn macht, wenn Sie ein Produkt entwickeln, auf dem das gesamte Unternehmen überleben wird.
Wenn Sie beispielsweise ein Produkt mit dem Namen des Unternehmens selbst erstellen, müssen Sie all diesen Grundsätzen mit einer Disziplin von nahezu 100% folgen.
Wenn Sie jedoch Software im Auftrag entwickeln, mit einer engen Planung, einem engen Budget und hohen Wettbewerbern auf dem Markt, müssen Sie sich wirklich überlegen, ob und in welchem Maße all diese Mitarbeiter für Sie in Ordnung sind. Und seien Sie vorsichtig, wenn die Kosten für eine so hochwertige Software Sie völlig vom Markt verdrängen.
Wenn Sie sich in einem Provisionsprojekt befinden, ist der Festpreis, bei dem Sie alle Annahmen und Einschränkungen für den Kunden und für Sie festlegen, die Benutzeroberfläche und die Datenbank sowie die zu verwendende Plattform oder sogar das zu verwendende Framework KEINE Details. Wird Teil des Projektumfangs sein. Der Kunde wird die Idee ändern? Er wird zahlen.
Tatsächlich werden Sie Framework verwenden, um Aufwand und Kosten zu reduzieren, ein bisschen mehr an sie zu koppeln und schneller zu planen. Natürlich werden Sie eine kleine Trennung schaffen, aber Sie werden den Rahmen ein wenig straffen, um zu beschleunigen.
Nach einigen Wochen oder Monaten möchte der Kunde etwas sehen, Sie können nicht sehen, "die Benutzeroberfläche ist ein Detail", ich habe ein schönes Geschäftsmodell zu zeigen.
Sie können nicht zwei Datenzugriffe erstellen, den ersten im Speicher und eventuell einen zweiten mit der realen Datenbank. Wer hat die Zeit, die doppelte Arbeit zu erledigen und so tief in die Abstraktion einzusteigen?
Und im Auftrag können Sie nicht zu viel "Nein" sagen, Sie werden draußen sein und ein anderer wird "Ja" sagen.
Wenn Sie im Auftrag sind, ist der Weg gut genug.
Natürlich werden Sie ein wenig entkoppeln, Sie werden TDD-kritische Regeln, Sie werden ein gefährliches "Ja" vermeiden; aber mit einem Grad an Disziplin von etwa 50%
In jedem Fall können diese 3 Bücher als "der Weg" betrachtet werden. Natürlich bleiben Sie bei der Kalibrierung des Nutzungsgrads, um ihn unter Berücksichtigung der Umgebung, in der Sie arbeiten, und des Marktes, in dem sich Ihr Unternehmen bewegt, anzuwenden.
Das Buch scheint eine Einführung in die Softwarearchitektur zu sein. Weitere Lektüre ist erforderlich, um diese Kunst zu beherrschen, aber keine andere Lektüre kann effektiv sein, ohne diese zuerst durchzugehen. Daher ist dies ein wesentlicher Softwareentwickler-Klassiker, um Teil Ihrer Bibliothek zu sein.
Keine 5 Sterne, weil es meiner Meinung nach zu wenig Informationen enthält. Ich meine nicht, dass es ein kurzes Buch ist, überhaupt nicht. Es revolutioniert jedoch nicht wirklich Ihre Sicht auf Design und Architektur, wenn Sie SOLID bereits in Ihrer Anwendung anwenden.
An vielen Stellen hatte ich das deutliche Gefühl, dass der Autor allgemein sprach und nur die Seiten mit nicht wesentlichen Informationen füllte.
Das Kapitel über das Entkoppeln von Tests über eine Test-API benötigt wirklich einige Beispiele. Insbesondere wegen bereits bestehender Kontroversen über die Fragilität von TDD usw.
Auf der anderen Seite ist es ein sehr kurzes Buch, im Grunde mit einer schnellen Zusammenstellung von allem, was er zuvor gesagt hat. Selbst wenn er neue Themen wie verteilte Systeme (SOA / Microservices) berührt, sind die Kapitel etwas flach. Ich habe mehr Codebeispiele verpasst, um einige Konzepte zu verdeutlichen.
Verstehen Sie mich nicht falsch: Es ist ein sehr gutes Buch, aber lesen Sie es als "Grundlage der Softwarearchitektur" (lesen Sie vorher das Inhaltsverzeichnis, damit Sie nicht enttäuscht werden).
ps.: Ich würde gerne sehen, wie Onkel Bob über andere - und spezifischere - Dinge wie DDD, CQRS, Event Sourcing, einige Cloud-Dienste und -Muster usw. schreibt.
Kapitel 34, verfasst von Simon Brown, ist sehr gut.