Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden

Modellieren Sie den Geschäftsbereich

Arbeiten Sie vom Geschäftsbereich zurück zum Softwaredesign, um sicherzustellen, dass die Software, die Sie schreiben, den Geschäftsanforderungen entspricht.

Verwenden Sie Methoden des Domain-Driven Designs (DDD) wie Event Storming, um den Geschäftsbereich zu modellieren. Event Storming hat ein flexibles Workshop-Format. Während des Workshops untersuchen Fach- und Softwareexperten gemeinsam die Komplexität des Geschäftsbereichs. Softwareexperten nutzen die Ergebnisse des Workshops, um den Entwurfs- und Entwicklungsprozess für Softwarekomponenten zu starten.

Schreiben und führen Sie Tests von Anfang an durch

Verwenden Sie testgesteuerte Entwicklung (TDD), um die Richtigkeit der Software, die Sie entwickeln, zu überprüfen. TDD funktioniert am besten auf Komponententest-Ebene. Der Entwickler entwirft eine Softwarekomponente, indem er zuerst einen Test schreibt, der diese Komponente aufruft. Diese Komponente hat am Anfang keine Implementierung, daher schlägt der Test fehl. In einem nächsten Schritt implementiert der Entwickler die Funktionalität der Komponente, indem er Test-Fixtures mit Scheinobjekten verwendet, um das Verhalten externer Abhängigkeiten oder Ports zu simulieren. Wenn der Test erfolgreich ist, kann der Entwickler mit der Implementierung echter Adapter fortfahren. Dieser Ansatz verbessert die Softwarequalität und führt zu besser lesbarem Code, da Entwickler wissen, wie Benutzer die Komponenten verwenden würden. Die hexagonale Architektur unterstützt die TDD-Methodik, indem sie den Anwendungskern trennt. Entwickler schreiben Unit-Tests, die sich auf das Kernverhalten der Domäne konzentrieren. Sie müssen keine komplexen Adapter schreiben, um ihre Tests durchzuführen. Stattdessen können sie einfache Scheinobjekte und Fixtures verwenden.

Verwenden Sie verhaltensgesteuerte Entwicklung (BDD), um die end-to-end Akzeptanz auf Featureebene sicherzustellen. In BDD definieren Entwickler Szenarien für Funktionen und überprüfen sie mit den Beteiligten aus dem Unternehmen. BDD-Tests verwenden so viel natürliche Sprache wie möglich, um dies zu erreichen. Die hexagonale Architektur unterstützt die BDD-Methodik mit ihrem Konzept von Primär- und Sekundäradaptern. Entwickler können primäre und sekundäre Adapter erstellen, die lokal ausgeführt werden können, ohne externe Dienste aufrufen zu müssen. Sie konfigurieren die BDD-Testsuite so, dass sie den lokalen Primäradapter zum Ausführen der Anwendung verwendet.

Führen Sie automatisch jeden Test in der kontinuierlichen Integrationspipeline durch, um die Qualität des Systems ständig zu bewerten.

Definieren Sie das Verhalten der Domain

Zerlegen Sie die Domäne in Entitäten, Wertobjekte und Aggregate (lesen Sie mehr über die Implementierung von domänengetriebenem Design) und definieren Sie deren Verhalten. Implementieren Sie das Verhalten der Domäne, damit Tests, die zu Beginn des Projekts geschrieben wurden, erfolgreich sind. Definieren Sie Befehle, die das Verhalten von Domänenobjekten aufrufen. Definieren Sie Ereignisse, die die Domänenobjekte aussenden, nachdem sie ein Verhalten abgeschlossen haben.

Definieren Sie Schnittstellen, die Adapter verwenden können, um mit der Domäne zu interagieren.

Automatisieren Sie Tests und Bereitstellungstests

Nach einem ersten Machbarkeitsnachweis empfehlen wir Ihnen, Zeit in die Implementierung der DevOps Verfahren zu investieren. Beispielsweise helfen Ihnen CI/CD-Pipelines (Continuous Integration and Continuous Delivery) und dynamische Testumgebungen dabei, die Qualität des Codes aufrechtzuerhalten und Fehler bei der Bereitstellung zu vermeiden.

Skalieren Sie Ihr Produkt mithilfe von Microservices und CQRS

Wenn Ihr Produkt erfolgreich ist, skalieren Sie Ihr Produkt, indem Sie Ihr Softwareprojekt in Microservices zerlegen. Nutzen Sie die Portabilität, die die hexagonale Architektur bietet, um die Leistung zu verbessern. Teilen Sie Abfragedienste und Befehlshandler in separate synchrone und asynchrone APIs auf. Erwägen Sie die Übernahme des CQRS-Musters (Command Query Responsibility Segregation) und der ereignisgesteuerten Architektur.

Wenn Sie viele neue Funktionsanfragen erhalten, sollten Sie erwägen, Ihr Unternehmen auf der Grundlage von DDD-Mustern zu skalieren. Strukturieren Sie Ihre Teams so, dass sie ein oder mehrere Funktionen als begrenzte Kontexte besitzen, wie zuvor inOrganisational diesem Abschnitt beschrieben. Diese Teams können dann Geschäftslogik mithilfe einer hexagonalen Architektur implementieren.

Entwerfen Sie eine Projektstruktur, die hexagonalen Architekturkonzepten entspricht

Infrastructure as Code (IaC) ist eine weit verbreitete Praxis in der Cloud-Entwicklung. Damit können Sie Ihre Infrastrukturressourcen (wie Netzwerke, Load Balancer, virtuelle Maschinen und Gateways) als Quellcode definieren und verwalten. Auf diese Weise können Sie mithilfe eines Versionskontrollsystems alle Änderungen an Ihrer Architektur verfolgen. Darüber hinaus ist es einfach, die Infrastruktur zu Testzwecken zu erstellen und zu verschieben. Wir empfehlen, dass Sie Ihren Anwendungscode und den Infrastrukturcode bei der Entwicklung Ihrer Cloud-Anwendungen im selben Repository aufbewahren. Mit diesem Ansatz ist es einfach, die Infrastruktur für Ihre Anwendung zu verwalten.

Wir empfehlen, Ihre Anwendung in drei Ordner oder Projekte aufzuteilen, die den Konzepten der hexagonalen Architektur entsprechen:entrypoints (Primäradapter),domain (Domäne und Schnittstellen) undadapters (sekundäre Adapter).

Die folgende Projektstruktur bietet ein Beispiel für diesen Ansatz beim Entwerfen einer API aufAWS. Das Projekt verwaltet Anwendungscode (app) und Infrastrukturcode (infra) im selben Repository, wie zuvor empfohlen.

app/  # application code
|--- adapters/  # implementation of the ports defined in the domain
     |--- tests/  # adapter unit tests
|--- entrypoints/  # primary adapters, entry points
     |--- api/  # api entry point
          |--- model/  # api model
          |--- tests/  # end to end api tests
|--- domain/  # domain to implement business logic using hexagonal architecture
     |--- command_handlers/  # handlers used to run commands on the domain
     |--- commands/  # commands on the domain
     |--- events/  # events emitted by the domain
     |--- exceptions/  # exceptions defined on the domain
     |--- model/  # domain model
     |--- ports/  # abstractions used for external communication
     |--- tests/  # domain tests
infra/  # infrastructure code 

Wie bereits erwähnt, ist die Domäne der Kern der Anwendung und ist von keinem anderen Modul abhängig. Es wird empfohlen, dendomain Ordner so zu strukturieren, dass er die folgenden Unterordner enthält:

Die Primäradapter sind die Zugangspunkte zur Anwendung, wie sie durch denentrypoints Ordner dargestellt werden. In diesem Beispiel wird derapi Ordner als primärer Adapter verwendet. Dieser Ordner enthält eine APImodel, die die Schnittstelle definiert, die der Primäradapter für die Kommunikation mit Clients benötigt. Dertests Ordner enthält end-to-end Tests für die API. Dies sind oberflächliche Tests, mit denen überprüft wird, ob die Komponenten der Anwendung integriert sind und harmonisch funktionieren.

Die sekundären Adapter, dargestellt durch denadapters Ordner, implementieren die externen Integrationen, die für die Domain-Ports erforderlich sind. Ein Datenbank-Repository ist ein gutes Beispiel für einen sekundären Adapter. Wenn sich das Datenbanksystem ändert, können Sie einen neuen Adapter schreiben, indem Sie die Implementierung verwenden, die von der Domäne definiert ist. Es ist nicht erforderlich, die Domain oder die Geschäftslogik zu ändern. Dertests Unterordner enthält externe Integrationstests für jeden Adapter.