Eine kurze Einführung in die saubere Architektur

In einem Open-Source-Projekt, zu dem ich beitragen wollte, wurde mir das Konzept der „sauberen Architektur“ vorgestellt.

Erstens war es ziemlich überwältigend, aber nach einigem Lesen machte es Sinn. Ich dachte, es könnte für andere hilfreich sein, wenn ich meine Gedanken aufschreibe.

Inhaltsverzeichnis

  • Visuelle Darstellungen
  • Das Konzept - in Stichpunkten dargestellt
  • Codebeispiel
  • Ressourcen

Visuelle Darstellungen

Ich denke, es ist immer gut, mit einer Visualisierung zu beginnen.

Hier sind die häufigsten Bilder dieses Konzepts.

Das Konzept - in Stichpunkten dargestellt

Erweitert von Quelle und Kredit: Mattia Battiston, unter CC BY 4.0

Der Wert, den es liefern kann

  • Eine effektive Teststrategie, die der Testpyramide folgt
  • Frameworks sind in einzelnen Modulen isoliert. Wenn (nicht wenn) wir unsere Meinung ändern, müssen wir nur an einem Ort eine Änderung vornehmen. Die App hat Anwendungsfälle, anstatt an ein CRUD-System gebunden zu sein
  • Schreiende Architektur alias es schreit seine beabsichtigte Verwendung. Wenn Sie sich die Paketstruktur ansehen, bekommen Sie ein Gefühl dafür, was die Anwendung tut, anstatt technische Details zu sehen
  • Die gesamte Geschäftslogik befindet sich in einem Anwendungsfall, sodass sie leicht zu finden ist und nirgendwo anders dupliziert wird
  • Es ist schwierig, das Falsche zu tun, da Module Kompilierungsabhängigkeiten erzwingen. Wenn Sie versuchen, etwas zu verwenden, für das Sie nicht bestimmt sind, wird die App nicht kompiliert
  • Es ist immer einsatzbereit, indem die Verkabelung des Objekts zum letzten Mal belassen wird. Oder indem Sie Feature-Flags verwenden, um alle Vorteile einer kontinuierlichen Integration zu nutzen
  • Mehrere Arbeiten an Geschichten, sodass verschiedene Paare problemlos gleichzeitig an derselben Geschichte arbeiten können, um sie schneller fertigzustellen
  • Guter Monolith mit klaren Anwendungsfällen, die Sie später in Microservices aufteilen können, sobald Sie mehr darüber erfahren haben

Entitäten

  • Stellen Sie Ihr Domain-Objekt dar
  • Wenden Sie nur die Logik an, die allgemein auf die gesamte Entität anwendbar ist (z. B. Überprüfen des Formats eines Hostnamens).
  • Einfache Objekte: keine Frameworks, keine Anmerkungen

Anwendungsfälle

  • Stellen Sie Ihre Geschäftsaktionen dar: Dies können Sie mit der Anwendung tun. Erwarten Sie einen Anwendungsfall für jede Geschäftsaktion
  • Reine Geschäftslogik, einfacher Code (außer vielleicht einigen Utils-Bibliotheken)
  • Der Anwendungsfall weiß nicht, wer ihn ausgelöst hat und wie die Ergebnisse dargestellt werden (z. B. auf einer Webseite oder - als JSON zurückgegeben oder einfach protokolliert usw.).
  • Wirft geschäftliche Ausnahmen

Schnittstellen / Adapter

  • Abrufen und Speichern von Daten von und zu einer Reihe von Quellen (Datenbank, Netzwerkgeräte, Dateisystem, Drittanbieter usw.)
  • Definieren Sie Schnittstellen für die Daten, die sie benötigen, um eine Logik anzuwenden. Ein oder mehrere Datenanbieter implementieren die Schnittstelle, aber der Anwendungsfall weiß nicht, woher die Daten stammen
  • Implementieren Sie die vom Anwendungsfall definierten Schnittstellen
  • Es gibt Möglichkeiten zur Interaktion mit der Anwendung und umfasst normalerweise einen Übermittlungsmechanismus (z. B. REST-APIs, geplante Jobs, GUI, andere Systeme).
  • Lösen Sie einen Anwendungsfall aus und konvertieren Sie das Ergebnis in das entsprechende Format für den Übermittlungsmechanismus
  • die Steuerung für eine MVC

Externe Schnittstellen

  • Verwenden Sie das am besten geeignete Framework (sie werden hier sowieso isoliert).

Codebeispiel

Siehe die Struktur auf GitHub.

Zunächst ist es wichtig zu verstehen, dass saubere Architektur ein Bündel von Organisationsprinzipien ist. Daher ist alles offen für persönliche Anpassungen, solange die Kernideen intakt bleiben. Das verknüpfte Repository ist eine Abzweigung des ursprünglichen Projekts, das mir diese Architekturentwurfsidee gebracht hat. Schauen Sie sich auch das ursprüngliche Projekt an, da es weitere Verbesserungen widerspiegelt.

Der Webminer-Ordner ist in die grundlegenden Ebenen unterteilt:

  1. Entitäten
  2. Anwendungsfälle
  3. interfaces_adapters
  4. external_interfaces

Es soll den sehr grundlegenden Ansatz für das Entwurfsmuster widerspiegeln.

  • Ausgehend von entitieskönnen Sie sehen, dass das Kernmodell dieses Projekts das istarxiv_document
  • Der nächste Ordner use_caseszeigt unseren Anwendungsfall, nämlich das Anfordern der arxiv-Seite
  • Danach gehen wir den interface_adaptersOrdner durch, der Adapter für Prozessanforderungen in einer REST-Anwendung oder zum Serialisieren bereitstellt
  • Die letzte und letzte Schicht ist external_interfaces. Hier verwenden wir den Flask-Server, um die REST-Funktionalität zu implementieren

Alle diese Schichten sind von den Kernschichten abhängig, aber nicht umgekehrt.

Ein wichtiger Hinweis: Dies ist nicht zu 100% korrekt im Repository implementiert.

Warum? Weil die Anwendungsfälle tatsächlich unterschiedlich sind. In der Realität besteht der Hauptanwendungsfall darin, die strukturierten Daten bereitzustellen. Ein weiterer Anwendungsfall besteht darin, die Daten von der arxiv-Seite abzurufen.

Haben Sie diesen Fehler in der Architektur entdeckt? Wenn ja, herzlichen Glückwunsch! Sie haben nicht nur genug Neugier in diesen Artikel gebracht, sondern wahrscheinlich auch die Prinzipien gut genug verstanden, um Ihren eigenen Fall zu erstellen und die Konzepte in der Realität anzuwenden!

Sind Sie einverstanden? Wenn nicht, warum? Danke, dass du meinen Artikel gelesen hast! Fühlen Sie sich frei, Feedback zu hinterlassen!

Ressourcen

Hier sind einige Artikel, die ich zum Verständnis des Konzepts der „sauberen Architektur“ hilfreich fand:

  • //8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
  • //www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
  • //github.com/mattia-battiston/clean-architecture-example
  • //medium.com/@tiagoflores_23976/how-choate-the-ropriate-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
  • //de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
  • //softwareengineering.stackexchange.com/questions/336677/what-is-the-difference-between-mvp-and-clean-architecture
  • //engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9
  • //gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
  • //medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
  • //marconijr.com/posts/clean-architecture-practice/

Daniel ist ein LL.M. Student des Wirtschaftsrechts, arbeitet als Softwareentwickler und Organisator von technischen Veranstaltungen in Wien. Seine aktuellen persönlichen Lernbemühungen konzentrieren sich auf maschinelles Lernen.

Verbinden auf:

  • LinkedIn
  • Github
  • Mittel
  • Twitter
  • Steemit
  • Hashnode