Saubere Architektur: Wo soll ich anfangen?

Im vorherigen Beitrag haben wir:

• Unsere Problemdomäne: eine ToDo-Anwendung mit einigen Anforderungen
• Ein Basis-Repository, das für die Verwendung von Python und Python Polylith konfiguriert ist.

Einige Entscheidungen sind also getroffen. Wir haben einige der Tools und haben entschieden, wie das Repository aussehen soll.

Das ist eines der Dinge, die ich an Polylith liebe: Es spielt keine Rolle, was Sie programmieren oder wie groß Ihre Organisation ist, alle Repositorys sehen gleich aus – wenn Sie mehr als eines benötigen.

Ihre Repository-Struktur ist konsistent, unabhängig davon, ob Sie FastAPI, Flask oder Django verwenden, eine oder mehrere Bibliotheken erstellen oder Hintergrundaufgaben mit Celery ausführen.

Einer der Hauptvorteile ist der optimierte Onboarding-Prozess für neue Entwickler. Vorausgesetzt, sie beherrschen Polylith, werden sie sich schnell mit der Projektstruktur vertraut machen: Wiederverwendbare Komponenten befinden sich im Komponentenordner, Einstiegspunkte im Basisordner, Demoskripte im Entwicklungsordner und so weiter.

Entitäten

Von Onkel Bob „The Clean Architecture“ sind Entitäten der Grundstein unserer Architektur, sie sind die innerste Schicht unserer Architektur. Wir müssen also mit ihnen beginnen, in Polylith sollten Entitäten als Komponenten leben.

Wie viele Komponenten?

Ich glaube, die Anzahl der Komponenten hängt von der Größe und Komplexität Ihrer Lösung ab. Ich empfehle jedoch, mit einer einzelnen Polylith-Komponente für Entitäten zu beginnen. Dieser Ansatz trägt dazu bei, eine klare und fokussierte Architektur aufrechtzuerhalten, insbesondere bei kleineren Projekten.

Warum eine einzelne Komponente für Entitäten?

• Diese Ebene kapselt Kerngeschäftsregeln, die für die gesamte Anwendung von grundlegender Bedeutung sind. Indem Sie es in einer einzigen Komponente belassen, stellen Sie Konsistenz sicher und vermeiden Duplikate.
• Eine einzelne Komponente vereinfacht die Abhängigkeitsverwaltung, da sie zu einer Abhängigkeit für alle anderen Ebenen wird.

Abhängigkeiten von Drittanbietern vermeiden.

Um externe Abhängigkeiten zu minimieren und die architektonische Flexibilität zu verbessern, sollten Sie sich bemühen, die Standardbibliothek von Python für die Darstellung von Entitäten zu verwenden. Dazu gehört die Nutzung von Datenstrukturen wie Diktat, Liste, Aufzählung, Funktionen, Klassen und neuerdings auch Datenklassen.

Warum sollten Sie Bibliotheken von Drittanbietern wie Pydantic oder Django Models meiden?

• Kopplung mit externen Frameworks: Die Verwendung dieser Bibliotheken kann zu unnötiger Kopplung mit bestimmten Frameworks führen.
• Erhöhte Komplexität: Externe Bibliotheken können die Komplexität erhöhen und potenzielle Wartungsprobleme verursachen.
• Reduzierte Flexibilität: Durch die Begrenzung externer Abhängigkeiten können Sie sich leichter an Änderungen in Anforderungen oder Technologie anpassen.

Durch die Einhaltung dieser Prinzipien können Sie eine robuste und wartbare Architektur erstellen, die gegenüber zukünftigen Änderungen widerstandsfähig ist.

ToDo-Entitäten

Unser Beispiel ist unkompliziert, wobei die Kernentität das „Aufgabenelement“ für Gordon ist. Wir können unserem Repository eine neue Komponente hinzufügen, aber die Wahl des richtigen Namens ist entscheidend.

Obwohl es verlockend sein könnte, generische Namen wie „core“ oder „main“ zu verwenden, ist es wichtig, Namen auszuwählen, die im Domänenkontext eine Bedeutung haben. Idealerweise sollten diese Namen mit der vom Kunden oder Produkteigentümer verwendeten Terminologie übereinstimmen. Durch die Verwendung domänenspezifischer Namen verbessern wir die Lesbarkeit und Wartbarkeit des Codes und machen es sowohl für Entwickler als auch für Stakeholder einfacher, die Struktur des Projekts zu verstehen.

Der Name des Repository-Arbeitsbereichs ist als todo definiert. Folglich folgen alle unsere Importe dem Format:

from todo.XYZ import ...
import todo.XYZ

Der Einfachheit halber verwenden wir in diesem Beispiel „Entities“ als Komponentennamen. In realen Szenarien sollten Sie jedoch Namenskonventionen in Betracht ziehen, die Ihre Domäne widerspiegeln. Wenn sich Ihre Anwendung beispielsweise um die Wiederherstellung von Dokumenten dreht, wäre eine Komponente namens „Recovery“ geeignet. Ebenso könnte eine Spieleanwendung der Übersichtlichkeit halber Tournaments_entities verwenden.

Das Erstellen der Komponente mit Python Polylith ist einfach:

poetry poly create component --name=entities
poetry poly sync
poetry install # it may be necessary

Dadurch wird ein Python-Paket im Komponentenordner hinzugefügt. Dies sind die neuen Einträge im Quellbaum:

./components
└── todo
    └── entities
        ├── __init__.py
        └── core.py
./test/components
└── todo
    └── entities
        ├── __init__.py
        └── test_core.py

Das Python-Polylith-Tool generiert Testbeispiele für uns, was eine nette Funktion ist. Dieses Verhalten kann in der Datei workspace.toml geändert werden, indem der Wert „enabled = true“ im Abschnitt [tool.polylith.test] auf „false“ gesetzt wird.

In der neuen Entitätenkomponente werden zwei Dateien hinzugefügt: __init__.py und core.py. Sie können das core.py-Modul umbenennen, um es Ihren Anforderungen besser anzupassen. Die gängige Praxis besteht darin, die öffentliche API des Pakets über __init__.py verfügbar zu machen und gleichzeitig die interne Organisation innerhalb anderer Module wie core.py aufrechtzuerhalten.

Von den Anforderungen haben wir derzeit nur eine Entität, den ToDo-Artikel:

@dataclass
class TodoItem:
    owner: str
    title: str
    description: str
    is_done: bool = False
    due_date: Optional[date] = None

Das Testen einer so einfachen Entität mag unnötig erscheinen, aber ich bevorzuge es, zumindest das Vorhandensein aller Felder zu testen. Während dies bei kleineren Projekten mit weniger Mitwirkenden möglicherweise nicht entscheidend erscheint, kann es bei größeren Projekten mit vielen Entwicklern erhebliche Probleme verhindern. Das Entfernen eines einzelnen Felds aus der Entität kann versehentlich verschiedene Teile der Anwendung beschädigen.

In der Pull-Anfrage für diesen Teil sehen Sie, dass ich einige grundlegende Tests für diese Entität hinzugefügt habe.

Da einige Tests bereits definiert sind, habe ich die Gelegenheit genutzt, einen GitHub-Workflow hinzuzufügen, um die Tests für jede Pull-Anfrage automatisch auszuführen.

Schlussfolgerungen

• Basiseinheiten der Anwendung
• CI-Setup

Was kommt als nächstes: Reden wir über Beharrlichkeit

Das obige ist der detaillierte Inhalt vonSaubere Architektur: Wo soll ich anfangen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!