Die Konzepte im Video Die Prinzipien sauberer Architektur von Onkel Bob Martin haben mir sehr gut gefallen . Aber ich denke, dieses Muster ist wie eine Kombination aus Abstract Factory- und Builder- Mustern im Kern.
Dies ist eine Möglichkeit, gute Programme zu schreiben, aber nicht die einzige.
Rails und Reactjs sind zwei Frameworks, die nicht für diese saubere Architektur sprechen. Rails erwartet, dass sich Ihre Geschäftslogik in den Modellen ( FatModels und SkinnyControllers ) befindet und innerhalb Ihrer Komponenten reagiert. Beide Ansätze koppeln Geschäftslogik und Framework-Code eng miteinander .
Ich finde auf keine der drei Arten etwas falsch. Es ist ein Urteilsruf, jemanden auszuwählen.
Im Video ist er jedoch der Meinung, dass eine saubere Architektur eine klare Grenze zwischen Geschäftslogik und Frameworks aufweisen sollte. Frameworks (Web, Android usw.) sollten Plugins sein, die sich in die Geschäftslogik einfügen. Er verspottet sogar subtil die Schienen im Video.
So ist „Clean Architecture“ von Bob Martin als Faustregel für alle Architekturen oder ist es nur eine der Optionen?
quelle
Antworten:
Die „saubere Architektur“ ist in Ordnung und bietet viele Vorteile. Beachten Sie jedoch Folgendes:
Die saubere Architektur ist größtenteils Robert C. Martins Umbenennung und Weiterentwicklung verwandter Ansätze wie der Onion-Architektur von Jeffrey Palermo (2008) und der hexagonalen Architektur („Ports und Adapter“) von Alistair Cockburn und anderen (<2008).
Unterschiedliche Probleme haben unterschiedliche Anforderungen. Die saubere Architektur und verwandte Ansätze machen die Entkopplung, Flexibilität und Abhängigkeitsinversion zu elf, opfern jedoch die Einfachheit. Dies ist nicht immer ein gutes Geschäft.
Der Vorläufer dieser Architekturen ist das klassische MVC-Muster von Smalltalk. Dadurch wird das Modell von der Benutzeroberfläche (Controller und Ansicht) getrennt, sodass das Modell nicht von der Benutzeroberfläche abhängt. Es gibt viele Variationen von MVC wie MVP, MVVM,….
Komplexere Systeme haben nicht nur eine Benutzeroberfläche, sondern möglicherweise mehrere Benutzeroberflächen. Viele Apps bieten eine REST-API an, die von jeder Benutzeroberfläche verwendet werden kann, z. B. von einer Web-App oder einer mobilen App. Dadurch wird die Geschäftslogik auf dem Server von diesen Benutzeroberflächen isoliert, sodass es dem Server egal ist, welche Art von App darauf zugreift.
In der Regel ist der Server weiterhin von Back-End-Diensten wie Datenbanken oder Drittanbietern abhängig. Dies ist vollkommen in Ordnung und führt zu einer einfachen Schichtarchitektur.
Die hexagonale Architektur geht noch weiter und unterscheidet nicht mehr zwischen Frontend und Backend. Jedes externe System kann eine Eingabe (Datenquelle) oder eine Ausgabe sein. Unser Kernsystem definiert die erforderlichen Schnittstellen (Ports) und wir erstellen Adapter für alle externen Systeme.
Ein klassischer Ansatz für eine starke Entkopplung ist eine serviceorientierte Architektur (SOA), bei der alle Services Ereignisse in einem gemeinsam genutzten Nachrichtenbus veröffentlichen und Ereignisse daraus verarbeiten. Ein ähnlicher Ansatz wurde später von Microservices populär gemacht.
Alle diese Ansätze haben Vorteile , z. B. die Vereinfachung des isolierten Tests des Systems (durch Ersetzen aller externen Systeme, an die es angeschlossen ist, durch Scheinimplementierungen). Sie erleichtern die Bereitstellung mehrerer Implementierungen für eine Art von Service (z. B. Hinzufügen eines zweiten Zahlungsprozessors) oder den Austausch der Implementierung eines Service (z. B. Wechsel von einer Oracle-Datenbank zu PostgreSQL oder Neuschreiben eines Python-Service in Go). .
Aber diese Architekturen sind die Ferrari der Architekturen: teuer und die meisten Leute brauchen sie nicht. Die zusätzliche Flexibilität der Clean Architecture usw. führt zu einer höheren Komplexität. Viele Anwendungen und insbesondere CRUD-Webapps profitieren davon nicht. Es ist sinnvoll, Dinge zu isolieren, die sich möglicherweise ändern, z. B. durch die Verwendung von Vorlagen zum Generieren von HTML. Es ist weniger sinnvoll, Dinge zu isolieren, die sich wahrscheinlich nicht ändern, z. B. die Hintergrunddatenbank. Was sich wahrscheinlich ändert, hängt vom Kontext und den geschäftlichen Anforderungen ab.
Frameworks machen Annahmen darüber, was sich ändern wird. Zum Beispiel geht React davon aus, dass sich Design und Verhalten einer Komponente gemeinsam ändern. Daher ist es nicht sinnvoll, sie zu trennen. Nur wenige Frameworks setzen voraus, dass Sie das Framework möglicherweise ändern möchten. Frameworks bieten daher eine gewisse Lock-In-Funktion. ZB macht es das Vertrauen von Rail in das (sehr aufgeschlossene!) Active Record-Muster schwierig, Ihre Datenzugriffsstrategie auf das (oft überlegene) Repository-Muster umzustellen. Wenn Ihre Änderungserwartungen nicht mit dem Framework übereinstimmen, ist es möglicherweise besser, ein anderes Framework zu verwenden. Viele andere Web-Frameworks machen keine Annahmen über den Datenzugriff.
quelle
Nicht annähernd.
Wenn du dir das anschaust:
Sie betrachten das Design eines Objektgraphen. Dies bestimmt, was über was weiß. Was in dieser Geschichte fehlt, ist, wie dieser Objektgraph aufgebaut wurde. Sorry, aber das findest du hier nicht. Bauarbeiten werden nicht erwähnt.
Sie können dies alles ohne abstrakte Fabriken und Erbauer aufbauen. Ich weiß, weil ich es getan habe . Ich wollte ihnen nicht einmal ausweichen. Ich liebe sie. Ich habe sie einfach nicht gebraucht. Ich habe gerade Referenzübergabe verwendet. Abhängigkeitsinjektion ist der schicke Begriff dafür.
Tatsächlich könnte ich alles, was Sie in diesem Diagramm sehen, in main aufbauen. Rufen Sie dann einfach eine Methode für ein Objekt auf, um das Ticken des Ganzen zu starten.
Jetzt müssen Dinge existieren, bevor Sie sie in andere Dinge hineinschieben können. Ich habe das hier untersucht und ihm dieses süße kleine Diagramm gegeben:
Und Sie können all das bauen, ohne auch nur zu gehen
main().Ich würde die Verwendung von Bauherren und Fabriken empfehlen, wenn Sie einen Stapel prozeduralen Konstruktionscodes in schöne, mundgerechte konzeptionelle Stücke aufteilen möchten. Aber es gibt nichts in sauberer Architektur oder in einer der anderen Modewortarchitekturen, das Sie dazu auffordern würde. Also, wenn Sie bleiben wollen
main(), gut. Bitte erbarme dich .Ich betrachte Clean Architecture als ein Schlagwort, mit dem Menschen zu einem Blog und einem Buch geführt werden. In diesem Blog und in diesem Buch finden sich sehr gute Erklärungen für sehr ähnliche ältere Architekturen mit älteren Namen, mit denen Menschen zu älteren Blogs und älteren Büchern geführt werden. Speziell Zwiebel sowie Ports und Adapter. Keine davon sind die einzigen architektonischen Optionen, die Sie haben.
Ich mag Onkel Bob, weil er ein großartiger Redner und Autor ist. Er lässt mich an Dinge denken, die ich sonst nicht hätte. Aber wenn Sie sich dadurch in einen religiösen Fanatiker verwandeln lassen, der darauf besteht, dass alles auf seine Weise getan werden muss, werden Sie schnell feststellen, dass die Aktualisierung der Dokumentation der nächste ist, mit dem Sie meinen Code erreichen können.
Die Modewortarchitekturen sind nützlich, wenn Sie langlebigen Code haben, der beibehalten werden muss, während sich die Welt um ihn herum ändert. Das ist, wenn es scheint. Wenn die Welt im Vergleich zum Code stabil ist, dann macht man die Dinge ohne guten Grund ausgefallen.
Egal wie großartig etwas scheint, es gibt einen Kontext, in den man es einfügen kann, der es absurd macht. Sorry, das ist auch keine Wunderkugel.
Du hast recht. Er tut. Onkel Bob ist der Ansicht, dass Frameworks wie Bibliotheken behandelt werden können. Und sie können. Aber selbst diese Entscheidung kostet dich etwas.
Was Herr Martin zu bewahren versucht, ist ein Raum, in dem Ihre allgemeine Sprache noch allgemein ist. Sie geben das auf, wenn Sie überall einen Rahmen verbreiten. Wenn Sie dies tun, gehen Sie den Weg, Ihre Sprache in eine domänenspezifische Sprache zu verwandeln. HTML ist eine domänenspezifische Sprache. Es macht seinen Job sehr gut, aber es gibt andere Jobs, die es überhaupt nicht machen kann.
Solange Ihre Bedürfnisse durch das Framework vorweggenommen werden, wird alles reibungslos verlaufen. Es ist schön, Ihre Bedürfnisse vorwegzunehmen. Es bringt Sie in eine Box, die die Dinge einfach hält. Verstehe einfach, was du aufgibst, um das zu bekommen. Wenn Sie Spring überall verbreiten, können Sie es nicht mehr als Java-Job bewerben. Es ist ein Java / Spring-Job. Ich könnte dasselbe über Ruby und Rails sagen, aber Rails hat vor langer Zeit Rubys Mittagessen gegessen.
quelle
So zitieren Sie das Video:
gefolgt von:
Die Architektur ist wie bei Serienbriefen nur eine Option unter vielen.
Was nicht optional ist, sind die Probleme, die die Architektur zu lösen versucht.
Wenn Sie verstehen, welche Probleme der SQL-Seriendruck im Vergleich zu anderen Lösungen verursacht, werden Sie über die Auswahl der Architektur informiert, und selbst wenn Sie gezwungen sind, "schlechte" Lösungen zu wählen, werden Sie diese Mängel bemerken und abmildern.
Wenn Sie einem architektonischen Stil folgen, nur weil er gut durchdacht ist, werden Sie wahrscheinlich Fehler machen und auf dieselben Probleme stoßen.
quelle
"Saubere Architektur" ist definitiv "nur" eine der Optionen. Ich würde behaupten, es ist eine der schlechten Optionen für die meisten Projekte, insbesondere für objektorientierte Projekte.
Hier ist eine satzweise Analyse von Onkel Bobs Artikel über saubere Architektur mit den Gründen für die obige Aussage:
Die saubere Architektur aus objektorientierter Perspektive
quelle
Clean Architecture besteht aus einer Reihe von Grundsätzen und Mustern, mit denen eine Reihe von häufigen Symptomen angegangen werden soll, denen Softwareentwicklungsunternehmen während der gesamten Lebensdauer der Erstellung komplexer Anwendungen häufig ausgesetzt sind. Herr Martin unternimmt in dem Buch große Anstrengungen, um die Symptome und Grundursachen auf der Grundlage seiner umfangreichen Erfahrung auf diesem Gebiet zu identifizieren und die Rolle der Architektur bei der Minderung dieser Bedenken zu klären.
Es ist jedoch weder eine Faustregel noch ein Allheilmittel gegen alle Übel. Wenn Sie das Buch lesen, haben Sie ein besseres Verständnis dafür, ob / wann / wie die von ihm befürworteten Prinzipien und Muster (und die damit verbundenen Kompromisse) anzuwenden sind. Wenn Sie das Buch nicht gelesen haben, werden Sie wahrscheinlich falsche Annahmen, Anwendungen, Beurteilungen und Aussagen treffen, die auf unvollständigen Informationen beruhen.
quelle