Den Bereich verstehen und das Team aufbauen: Die Grundlagen des Wandels (II)

Um ein komplexes Projekt in Angriff zu nehmen, ist eine umfassende Kontexterfassung erforderlich, während gleichzeitig das Domänenwissen aus einer neuen Perspektive betrachtet und die Erkenntnisse von Domänenexperten genutzt werden können. Dieser Ansatz richtet das technische Team an den Geschäftszielen aus und erstellt einen grundlegenden Fahrplan für eine fundierte Entscheidungsfindung während des gesamten Produktlebenszyklus.

Erste Wissensbeschaffungssitzungen mit dem vorherigen Team und aktuellen Anwendungsbenutzern erwiesen sich als unproduktiv. Wir haben kurz darüber nachgedacht, trotz der damit verbundenen Risiken unabhängig vorzugehen.

EventStorming: Enthüllung der Domäne

Als technischer Leiter habe ich mich angesichts der Komplexität des Projekts und der Eigenverantwortung des Teams von Anfang an für einen domänenorientierten Ansatz eingesetzt. Dadurch wurde die Domäne zentriert und ein gemeinsames Verständnis (allgegenwärtige Sprache) gefördert, das die Kommunikation optimierte und die Abbildung des aktuellen Status der Anwendung erleichterte.

Wir haben EventStorming-Sitzungen mithilfe einer Miro-Vorlage initiiert, die Struktur und eine Legende für eine effektive Fokussierung bereitstellte. Eine vorherige Vertrautheit mit EventStorming-Konzepten, entweder durch Vorbereitung vor der Sitzung oder durch erste Erklärungen, ist von großem Vorteil.

Unser strukturierter EventStorming-Prozess umfasste:

1. Erkunden von Domänenereignissen (Big Picture): Identifizieren, chronologisches Ordnen und Validieren wichtiger Systemereignisse mit Domänenexperten, Hervorheben von Lücken und Abhängigkeiten.
2. Verfeinerung und Analyse:Erläuternde Anmerkungen hinzufügen, Fragen dokumentieren, jedes Ereignis gründlich analysieren und kritische Entscheidungspunkte lokalisieren.
3. Domänenmodellierung: Aggregate und Grenzen identifizieren, Akteure und Rollen definieren, auslösende Befehle festlegen, Richtlinien und Geschäftsregeln dokumentieren und interne/externe Ereignisauslöser identifizieren.
4. Dokumentation und Validierung:Gesammelte Informationen organisieren und bereinigen, klare Beziehungen herstellen, das Modell mit Stakeholdern validieren und Referenzdokumentation erstellen.

EventStorming lieferte nicht nur Domänenverständnis, sondern auch eine Grundlage für die strategische und taktische Anwendung der Prinzipien des Domain-Driven Design (DDD).

Strategisches domänengesteuertes Design

Ein entscheidender erster Schritt war die strategische Strukturierung der Domain. Die Komplexität des Systems und die Notwendigkeit einer technischen/geschäftlichen Abstimmung führten zur Einführung der DDD-Prinzipien. Context Mapping erwies sich als unschätzbar wertvoll, selbst innerhalb unseres Monolithen, der auf eine Umgestaltung wartete. Wir haben Bounded Contexts identifiziert, die in einem einzigen technischen Kontext mit einem gemeinsamen Kernel arbeiten. Obwohl diese Analyse nicht gründlich untersucht wurde, führte sie das Projekt zu einer domänenorientierten Architektur, die sowohl die technische Entwicklung als auch die teamübergreifende Zusammenarbeit verbesserte.

Grenzen definieren (Begrenzte Kontexte)

Identifizierung Begrenzter Kontexte klärte die Beziehungen zwischen Systemen und externen Systemen, vereinfachte die Komplexität und legte eine Grundlage für die zukünftige Modularisierung. Diese ersten Entscheidungen werden die Zerlegung des Monolithen in überschaubare Komponenten steuern, die auf definierte Kontexte ausgerichtet sind. Dies erleichterte auch die Priorisierung und Identifizierung von Bereichen zur Vereinfachung, Entkopplung oder Eliminierung. Wir haben uns auf die Implementierung von Anti-Corruption Layers (ACL) für die externe Systeminteraktion konzentriert, um die Systemintegrität zu wahren.

Fünf Schlüsselkontexte wurden identifiziert:

• Auftragszuweisung
• Etikettengenerierung
• Auftragsvorbereitung
• E-Commerce-Integration
• Vorbereitung von Großbestellungen

Diese Entscheidungen förderten eine nachhaltige Architektur und richteten die Entwicklung auf die Geschäftsanforderungen aus.

Allgegenwärtige Sprache

Die Etablierung einer robusten, allgegenwärtigen Sprache erwies sich als entscheidend. Die Vorteile einer gemeinsamen Sprache, die durch die Zusammenarbeit zwischen Fachexperten und Entwicklern entsteht, überwiegen bei weitem den Übersetzungsaufwand oder Fehlinterpretationen. Diese lebendige Ressource verband das technische Team mit Domänenexperten, verbesserte die Kommunikation, reduzierte Missverständnisse und sorgte für eine genaue Domänendarstellung im Code. Dies förderte effiziente, geschäftsorientierte technische Lösungen.

Taktisches domänengesteuertes Design

Dem strategischen Rahmen folgend haben wir taktische DDD-Prinzipien implementiert, um den Code zu strukturieren, die Domänenrealität widerzuspiegeln und langfristige Nachhaltigkeit sicherzustellen.

Entitäten und Wertobjekte

Es ist von entscheidender Bedeutung, den Unterschied zwischen Entitäten und Wertobjekten zu verstehen.

Entitäten

Entitäten besitzen eine einzigartige, dauerhafte Identität, auch bei Attributänderungen. Beispiele hierfür sind:

• Bestellung
• Produkt
• Träger
• Shop
• Kunde

Wertobjekte

Wertobjekten fehlt die individuelle Identität; Ihr Wert definiert sie. Identische Attribute bedeuten Gleichwertigkeit. Sie sind unveränderlich und ideal zum Kapseln von Konzepten, die in der gesamten Domäne auftreten. Beispiele hierfür sind:

• Produktreferenz
• ProductEan13
• OrderReference
• Preis
• Gewicht
• Versandnummer

Dieser Ansatz führte zu einem verständlicheren und modulareren Code mit klar definierten Verantwortlichkeiten.

Beispielwertobjekt:

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Dienstleistungen

Dienste werden nach Zweck und implementierten Mustern kategorisiert.

Domain-Dienste

Domänendienste kapseln Geschäftslogik, die nicht in Entitäten oder Werte passt, und arbeiten strikt innerhalb der Domänenregeln ohne Infrastrukturabhängigkeiten.

<code class="language-php"><?php
readonly class ProductEan13
{
    public string $value;

    public function __construct(string $value)
    {
        $pattern = '/^\d{13}$/';
        if (!preg_match($pattern, $value)) {
            throw new \Exception('Invalid product Ean13');
        }
        $this->value = $value;
    }
}</code>

Anwendungsdienste

Application Services koordinieren Domänenvorgänge mit externen Interaktionen, zentralisieren komplexe Vorgänge und trennen Domäne und Infrastruktur. Dazu gehören Anwendungsfälle, Befehlshandler und Ereignishandler.

Infrastrukturdienstleistungen

Infrastrukturdienste verarbeiten externe Komponenteninteraktionen (Datenbanken, Dateisysteme usw.) und fungieren als Adapter, um Domänenunabhängigkeit aufrechtzuerhalten.

<code class="language-php"><?php
class CheapestCarrierGetter
{
    public function get(
        DeliveryOptionCarrierCollection $deliveryOptionCarriers,
        Weight $orderWeight,
        Country $country,
        PostalCode $postalCode,
        bool $isCashOnDelivery = false,
    ): Carrier {
        // Logic to get the cheapest carrier
    }
}</code>

Dienstleistungsklassifizierung

Dienste werden nach Funktion und zugehörigen Entwurfsmustern klassifiziert: Transformatoren, Builder, Fabriken, Präsentatoren, Benachrichtiger, Validatoren und Clients.

Diese anfängliche Domänenmodellierung, obwohl unvollständig und iterativ, förderte die Beteiligung und das Engagement des Teams. Weitere Verfeinerungen und Umstrukturierungen wurden erwartet.

Empfohlene DDD-Ressourcen:

• „Domain-Driven Design: Tackling Complexity in the Heart of Software“ von Eric Evans
• „Implementing Domain-Driven Design“ von Vaughn Vernon
• „Domain-Driven Design in PHP“ von Carlos Buenosvinos, Christian Soronellas und Keyvan Akbary

Das Team aufbauen: Tuckman's Stages

Die Einführung von DDD erfolgte parallel zur Teambildung nach Tuckmans Phasen (Forming, Storming, Norming, Performing).

Umformen

Erste Teammitglieder überprüften das Projekt, dokumentierten Abläufe und legten technische und organisatorische Grundlagen (Prozesse, Standards, Tools) fest.

Stürmend

Kleinere Meinungsverschiedenheiten führten zur Definition von Arbeitsstilen, Kommunikationsmethoden und Entscheidungsprozessen.

Normierung

Teamvereinbarungen, Codierungsstandards, Entwicklungsprozesse, WIP-Limits, Bereitstellungsregeln, technisches Schuldenmanagement und ADRs wurden festgelegt.

Auftritt

Der etablierte Rahmen ermöglichte eine effiziente Produktentwicklung, die Priorisierung wertvoller Initiativen und die Förderung einer Kultur der kontinuierlichen Verbesserung.

Dokumentation: Das Diátaxis-Modell

Die Dokumentation wurde mithilfe von GitLab Pages und Jekyll mit dem Just the Docs-Thema verwaltet, wobei dem Diátaxis-Modell gefolgt wurde: Tutorials, Leitfäden, Erklärungen und Referenzen. Die Automatisierung der Dokumentation mithilfe von Event Catalog und AsyncAPI war geplant, aber nicht vollständig implementiert.

Das obige ist der detaillierte Inhalt vonDen Bereich verstehen und das Team aufbauen: Die Grundlagen des Wandels (II). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!