Leitfaden eines Backend-Entwicklers / Sudo Null IT News

Hallo zusammen, mein Name ist Avksentii, ich bin Backend-Entwickler bei inDriver. Ich denke, dass jeder unerfahrene Entwickler schon einmal mit dem Problem konfrontiert war, wie man die Architektur und Struktur des Projekts richtig aufbaut. Schließlich ist die Organisation des Projektcodes ein sich ständig weiterentwickelndes Problem, und das Befolgen einer Standardstruktur hält den Code sauber und verbessert die Teamproduktivität.

Als ich anfing, Go zu schreiben, verbrachte ich viel Zeit damit, nach Standards für die Strukturierung eines Projekts zu suchen. Infolgedessen habe ich nie einen offiziellen und genauen Standard gefunden – entweder waren die Informationen unvollständig oder es war nicht das, was benötigt wurde. Ich habe mich entschieden, meinen Leitfaden basierend auf Erfahrung zu schreiben. Es ist für Anfänger-Entwickler und konzentriert sich darauf, wie man ein Projekt in Golang strukturiert.

Warum ich mich entschieden habe, diesen Artikel zu schreiben

Eine richtig aufgebaute Projektarchitektur und -struktur zu Beginn trägt zu einer reibungslosen Entwicklung, Skalierung und einfachen Einführung neuer Entwickler in das Projekt bei. Natürlich kann die flache Struktur auch für kleine Projekte mit einer einzigen Hauptdatei verwendet werden, aber für große ist es unpraktisch.

Ich habe viele Projekte gesehen und von jedem etwas für mich mitgenommen. Ich empfehle Ihnen, sich umzusehen dieses Projekt – Viele lassen sich beim Erstellen einer Struktur davon leiten. In meinem Beispiel wird es eine kompaktere Struktur geben – wir werden das /internal-Verzeichnis im Detail analysieren.

Natürlich erhebt die Methode nicht den Anspruch, die beste oder einzige Möglichkeit zu sein. Aber ich denke, es ist ein guter Anfang. Schauen wir uns die Struktur des Projektstamms an:

Wurzelstruktur der AnwendungWurzelstruktur der Anwendung

Verzeichnisse

/cmd

Der Einstiegspunkt für unsere Anwendung. Der Verzeichnisname für jede Anwendung muss mit dem Namen der ausführbaren Datei übereinstimmen, die Sie erstellen möchten. Platzieren Sie nicht viel Code in diesem Verzeichnis. Am häufigsten wird eine kleine Hauptfunktion verwendet, die den gesamten erforderlichen Code aus den Verzeichnissen /internal und /pkg importiert und aufruft.

/cmd Verzeichnisstruktur/cmd/interne Verzeichnisstruktur

Das Herzstück unserer Anwendung – hier speichern wir die gesamte interne Logik der Anwendung. /internal kann nicht in andere Anwendungen und Bibliotheken importiert werden. Der hier geschriebene Code ist ausschließlich für die interne Verwendung innerhalb der Codebasis bestimmt. Seit Go 1.4 wurde ein Mechanismus definiert, der verhindert, dass Pakete von außerhalb des Projekts importiert werden, wenn sie sich innerhalb von /internal befinden.

In /internal speichern wir die Geschäftslogik des Projekts und arbeiten mit Datenbanken. Im Allgemeinen die gesamte mit dieser Anwendung verbundene Logik. Je nach Architektur können Sie die Struktur inside /internal auf unterschiedliche Weise aufbauen. Aber ich werde nicht tief darauf eingehen, sondern oberflächlich zeigen, wie es aussieht. Ich werde ein Beispiel für eine dreistufige Architektur geben, wenn die Anwendung in drei Schichten unterteilt ist:

  1. Transport.

  2. Geschäft.

  3. Datenbank.

Die Logik sollte so aufgebaut sein, dass sich die Schichten hierarchisch von oben nach unten ansprechen und umgekehrt. Es ist nicht erlaubt, dass eine Schicht die mittlere überspringt (z. B. die Transportschicht direkt zur Datenbank) und die untere nicht mit der oberen kommuniziert (z. B. die Datenbank geht zur Transportschicht).

Dreistufiges ArchitekturmodellDreistufiges Architekturmodell

Transportschicht:

Die Netzwerkschicht einer Anwendung, auf der der Endbenutzer mit der Anwendung interagiert. Nach Bearbeitung der Anfrage gehen alle gesammelten Informationen in die darunter liegende Schicht.

Geschäftsschicht:

Wie der Name schon sagt, enthält es die Geschäftslogik, die die Kernfunktionalität der Anwendung unterstützt. Wenn Datenbanken an der Logik beteiligt sind, gehen wir eine Ebene nach unten.

Datenbankschicht:

Verantwortlich für die Interaktion mit persistenten Speichern wie Datenbanken und anderer Informationsverarbeitung, die nicht mit dem Unternehmen in Zusammenhang stehen. Zum Beispiel Lesen und Schreiben in eine Datenbank.

Verzeichnisse /intern:

  • /app
    Der Punkt, an dem alle unsere Abhängigkeiten und Logik zusammengestellt werden und die Anwendung ausführen. Run-Methode, die von /cmd aufgerufen wird.

  • /config
    Initialisierung der allgemeinen Konfigurationen der Anwendung, die wir im Stammverzeichnis des Projekts registriert haben.

  • /database (Schicht Datenbank)
    Die Dateien enthalten Methoden für die Interaktion mit Datenbanken.

  • /models (Schicht Datenbank)
    Datenbanktabellenstrukturen.

  • /Dienstleistungen (Geschäftsschicht)
    Die gesamte Geschäftslogik der Anwendung.

  • /transport (Transportschicht)
    Hier speichern wir die HTTP-Einstellungen, Handler, Ports usw. des Servers.

/interne Verzeichnisstruktur/internal/pkg Verzeichnisstruktur

Wenn wir in /internal Code gespeichert haben, den wir nicht in andere Anwendungen importieren konnten, dann speichern wir in /pkg Bibliotheken, die in Anwendungen von Drittanbietern verwendet werden. Dies ist notwendig, um sie später in ein anderes Projekt zu importieren und Code nicht von Projekt zu Projekt zu duplizieren. Im Allgemeinen speichern wir hier benutzerdefinierte oder gemeinsam genutzte Bibliotheken.

Sie dürfen dieses Verzeichnis nicht verwenden, wenn das Projekt sehr klein ist und das Hinzufügen einer neuen Verschachtelungsebene keinen praktischen Sinn macht.

/configs

Statische Konfigurationen unserer Anwendung im Zusammenhang mit dem Anwendungserstellungsprozess. Normalerweise sind dies yaml-Dateien.

/API

Dokumentation für Ihre API. OpenAPI- oder Swagger-Spezifikationen, JSON-Schemadateien, Protokolldefinitionsdateien.

/bauen

Konfigurationsdateien für den Projekt-Build, den Docker-Container usw.

/Bereitstellungen

Enthält Dateien im Zusammenhang mit der Bereitstellung: Ansible Playbooks, Docker Compose-Manifeste, Kuberntes-Manifeste und -Einstellungen, Helm-Diagramme.

/docs

Das Dokumentieren von Code ist ein wichtiger Teil am Anfang eines Projekts. Daher speichern wir hier alle Code- und Designdokumentationen (zusätzlich zur automatischen Godoc-Dokumentation).

README.md

Es ist schwer zu erwarten, dass jemand in Ihren Code eintauchen möchte, es sei denn, er hat eine allgemeine Beschreibung des Projekts erhalten. Daher wird auch die README-Datei benötigt.

Gemeinsame Verzeichnisse

Ich möchte allgemeine Verzeichnisse anzeigen, die ich nicht in mein Projekt aufgenommen habe. Sie können sich mit ihnen vertraut machen und bei Bedarf selbst hinzufügen.

/Skripte

Skripte zum Erstellen, Installieren, Analysieren und für andere Vorgänge im Projekt. Sie halten das Haupt-Makefile klein und einfach.

/Testdaten

Zusätzliche externe Anwendungen und Daten zum Testen. Sie können die /test-Verzeichnisstruktur nach Belieben organisieren. Bei großen Projekten ist es sinnvoll, ein verschachteltes Verzeichnis mit Testdaten anzulegen.

/Werkzeug

Tools zur Projektunterstützung. Beachten Sie, dass diese Tools Code aus den Verzeichnissen /pkg und /internal importieren können.

/Vermögenswerte

Andere Ressourcen, die Sie für den Einstieg benötigen: zum Beispiel Bilder und Logos.

/Netz

Dieses Verzeichnis wird benötigt, wenn Sie eine Webanwendung implementieren. Hier sind die speziellen Komponenten für Webanwendungen: statische Webressourcen, serverseitige Vorlagen und Einzelseitenanwendungen.

/Migrationen

Alle datenbankbezogenen Migrationen sind hier: SQL-Dateien zum Beispiel.

Fazit

Natürlich müssen Sie sich nicht strikt an meine Struktur halten. Du kannst mitmachen und alles selbst bearbeiten. Aber als ich anfing, fehlte mir eine so detaillierte Anleitung. Ich hoffe, dieser Artikel hat Ihnen geholfen!

Nur für den Fall, ich werde gehen Verknüpfung zu Ihrem öffentlichen Beispielprojekt auf GitHub. Wenn Sie Fragen haben, stellen Sie sie in den Kommentaren.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *