Lassen Sie uns über DDD in PHP sprechen

DDD ist die Abkürzung für „Domain Driven Design“, was auf Chinesisch oft als domänengesteuertes Design übersetzt wird. Heute werden wir DDD in PHP einführen. Sie können bei Bedarf darauf zurückgreifen.

Was ist DDD? Bevor wir verstehen, was DDD ist, wollen wir zunächst besprechen, was es nicht ist.

DDD ​​​​ist kein Software-Framework. Es gibt jedoch Frameworks, die auf DDD-Ideen basieren, wie beispielsweise Axon, ein in Java implementiertes Microservice-Software-Framework mit DDD als Leitidee.
DDD ​​​​ist kein Software-Designmuster. Es handelt sich nicht um ein Entwurfsmuster wie Factory oder Singleton. Im DDD-Denken werden jedoch Entwurfsmuster wie Repository vorgeschlagen.
DDD ​​​​ist kein Systemarchitekturmuster. Es handelt sich nicht um ein Architekturmuster wie MVC. DDD-Ideen haben jedoch Architekturmuster wie Event Sourcing (Event Sourcing) und Lese-/Schreibisolation (Command Query Responsibility Segregation) vorgeschlagen.
Was genau ist DDD?

Software ist ein Werkzeug, das entwickelt wurde, um Menschen zu dienen und die menschliche Produktivität zu verbessern. Ein CRM ist beispielsweise ein Tool, das sich auf die Verwaltung von Kundendaten konzentriert und Händlern hilft, mit Kunden in Kontakt zu bleiben.

Die Essenz von Software ist der im Computer ausgeführte Code. Wie man den abstrakten Code den Bereichen menschlicher Belange genauer zuordnen kann, ist ein Thema, mit dem sich Softwareentwickler beschäftigt haben, sei es funktionale Programmierung (FP) oder objektorientiert Beim Programmieren (OOP) geht es darum, Entwicklern dabei zu helfen, Softwaremodelle zu entwickeln, die für das Fachgebiet relevanter sind.

Bei herkömmlichen Softwareentwicklungsmethoden stoßen wir häufig auf eine Reihe technischer und nichttechnischer Probleme, die sich auf die Softwarequalität auswirken:

Entwickler sind technologiebegeistert, aber es mangelt ihnen an Design und Geschäftsdenken. Ohne die Geschäftsanforderungen vollständig zu verstehen, arbeiten Entwickler hinter verschlossenen Türen und niemand kümmert sich um die Funktionalität, selbst wenn sie online verfügbar ist.
Code-Eingabe statt Geschäftseingabe. Technisches Personal hat eine besondere Vorliebe für die Implementierung von Technologie, und es gibt Situationen, in denen es nicht nötig ist, ein Bullenmesser zu verwenden, um ein Huhn zu töten.
Zu viel Wert auf die Datenbank. Eine Entwicklung, die sich eher auf das Datenbankdesign als auf das Geschäft konzentriert, führt oft dazu, dass die Software nicht in der Lage ist, sich an die sich ständig ändernde Geschäftslogik anzupassen.
DDD ​​​​ist eine Designidee, die von der Domäne (Geschäft) ausgeht und darauf abzielt, die Komplexität der Softwaremodellierung zu lösen. Wir können sie auch als Modellierungsmethode verstehen. Die Designphilosophie von

DDD ​​gliedert sich in zwei Teile: Strategie und Taktik.

Wir können strategisches Design als Design auf Makroebene verstehen. Sein Zweck umfasst die Analyse der Komplexität des Geschäfts, die Aufteilung des Geschäftsumfangs, die Steuerung der Geschäftsintegrationsmethode usw. Wir können taktisches Design als Design auf Mikroebene (Codeebene) verstehen, das uns eine Reihe von Tools zur Implementierung der Geschäftslogik zur Verfügung stellt.

Strategisches Design

Universelle Sprache (allgegenwärtige Sprache)

Sprache ist das grundlegende Werkzeug für die menschliche Kommunikation. Entwickler sind es jedoch gewohnt, Fachbegriffe und Fachexperten zu verwenden (Fachexperten beziehen sich hier im Allgemeinen auf Experten, die sich mit der Wirtschaft auskennen, z (z. B. Benutzer und Kunden) usw.) kümmern sich nicht um technische Terminologie, was zu unvermeidlichen Kommunikationsproblemen führt. Sobald Kommunikationsprobleme auftreten, wird es für die entwickelte Software schwierig sein, die eigentlichen Schwachstellen von Fachexperten zu lösen.

Universelle Sprache ist der Grundstein des DDD-Denkens. Es handelt sich um eine Kommunikationssprache, die gemeinsam von Entwicklern und Fachexperten erstellt wird und die im Team beliebt ist, um ohne Barrieren zu kommunizieren.

Dies erfordert, dass Entwickler den Fachjargon aufgeben, mit Domänenexperten zusammenarbeiten, sich auf Geschäftsthemen wie Domänenexperten konzentrieren, gemeinsam die Terminologie im Unternehmen erforschen und verfeinern und eine gemeinsame Sprache schaffen.

Universelle Sprache kann oft direkt auf Code angewendet werden. Sie kann direkt als Klasse oder Methode einer Klasse geschrieben werden.

Zum Beispiel bei der Entwicklung eines Warenkorbs, anstatt Fachbegriffe zu verwenden:

Cart::create(): Einen Warenkorb erstellen.
Cart::updateStatus(): Aktualisieren Sie den Warenkorbstatus.
Cart::remove(): Den Warenkorb entfernen.
Wir könnten genauso gut eine gemeinsame Sprache verwenden, die näher am Geschäft ist:

Cart::init(): Erstellen Sie einen Warenkorb.
Cart::addItemToCart(): Artikel hinzufügen.
Cart::removeItemFromCart(): Entfernen Sie den Artikel.
Cart::empty(): Leeren Sie den Warenkorb.
Bei Verwendung von Letzterem müssen Entwickler nicht die Bedeutung jeder Klassenmethode erklären, und Domänenexperten können den Zweck jeder Klassenmethode direkt verstehen. Entwickler können sich sogar mit Domänenexperten zusammensetzen und mit Code arbeiten, um Geschäftsprozesse zu verbessern.

Begrenzter Kontext

Nachdem wir die Freiheit der universellen Sprache erkannt haben, müssen wir den begrenzten Kontext verwenden, um die Nutzungsgrenzen jedes Satzes universeller Sprachen anzugeben. Der begrenzte Kontext ist die Grenze zwischen Semantik und Kontext. Jedes darin enthaltene Element hat seine eigene spezifische Bedeutung. Das heißt, jedes Konzept ist in einem begrenzten Kontext einzigartig und es ist keine Polysemie zulässig.

Wir können den begrenzten Kontext anhand eines einfachen Beispiels erklären. Im begrenzten Kontext eines Warenkorbs können wir beispielsweise das Wort „Benutzer“ verwenden, um den Kunden darzustellen, der das Produkt gekauft hat. In einem Registrierungssystem können wir das Wort „Benutzer“ verwenden, um auf ein Konto mit einem Benutzernamen und einem Passwort zu verweisen. Obwohl die Wörter gleich sind, haben sie in verschiedenen begrenzten Kontexten unterschiedliche Bedeutungen.

Wir verwenden begrenzten Kontext und universelle Sprache, um das Geschäft auf Sprachebene aufzuteilen. Der begrenzte Kontext gibt jedem Element in der Domäne ein klares Konzept, sodass Entwickler nicht in Versuchung geraten, mehrere Konzepte, die ein Element unterstützen, in ihren Köpfen zu flashen und das Schreiben von „großem Schlamm“-Code zu vermeiden.

Subdomain

Wenn der begrenzte Kontext das Geschäft auf Sprachebene aufteilen soll, dann soll die Subdomain den Geschäftswert des Unternehmens aufteilen. Jedes Unternehmen hat seinen eigenen Schwerpunkt. Auch wenn es sich um E-Commerce-Plattformen handelt, die gleich aussehen, ist Taobao ein offenes Plattformmodell, während JD.com ein Wertschöpfungsketten-Integrationsmodell ist. Ein offensichtlicher Unterschied besteht darin, dass Taobao die Logistik von Drittanbietern nutzt JD.com baut ein eigenes Logistiksystem auf.

Warum sollten Sie sich als Entwickler also für ein Geschäftsmodell interessieren, das scheinbar nichts mit Ihnen zu tun zu haben scheint? Im Gegenteil: Nur wenn wir die Struktur eines Unternehmens verstehen, können wir ein System mit klaren Prioritäten entwickeln, um die schnelle Entwicklung eines Unternehmens zu unterstützen.

Subdomain ist ein solches Tool, das uns hilft, Prioritäten zu setzen.

Es gibt drei Arten von Subdomains:

• Kerndomäne: Dies ist der Bereich im System, der die größte Investition erfordert und die zentrale Wettbewerbsfähigkeit des gesamten Unternehmens darstellt. Wir müssen viele Ressourcen und Ressourcen aufwenden, um den Kernbereich zu polieren, der mit dem Überleben eines Unternehmens zusammenhängt. Zum Beispiel das selbstgebaute Logistiksystem von JD.com.

• Unterstützende Domäne: Diese Domäne ist nicht das Kerngeschäft eines Unternehmens, aber die Kerndomäne ist untrennbar damit verbunden. Sie kann mithilfe von Outsourcing-Anpassungslösungen implementiert werden. Zum Beispiel Authentifizierungskontext und Berechtigungskontext.

• Generische Domain: Wenn es eine ausgereifte Lösung gibt, kann die generische Domain eine fertige Lösung erwerben. Wenn nicht, können Sie auch Outsourcing nutzen. Die Investition in die allgemeine Domain sollte minimal sein. Für Taobao beispielsweise ist die Logistik die allgemeine Domäne.

Es gibt unterschiedliche Meinungen über die Beziehung zwischen begrenztem Kontext und Subdomains, während andere 1:N befürworten. Persönlich befürworte ich 1:1, da ich stark vom Autor des Buches „Implementing Domain-Driven Design“ beeinflusst bin.

Context Mapping

In einem riesigen System müssen bestimmte Abhängigkeiten zwischen begrenzten Kontexten bestehen. Wie ordnet man Konzepte von einem Kontext in einen anderen zu? Wir verwenden Kontextzuordnung.

Im Folgenden sind verschiedene Beziehungstypen der Kontextzuordnung aufgeführt:

• Partnerschaft

• Gemeinsamer Kernel

• Kunden-Lieferanten-Entwicklung

• Konformist

• Anticor Unterbrechungsschicht

• Open Host Service

• Veröffentlichte Sprache

• SeparateWay

• Big Ball of Mud

Die oben genannten Konzepte sind relativ abstrakte Konzepte, und manchmal kann es mehrere Beziehungen zwischen zwei begrenzten Kontexten geben.

Die oben genannten sind einige Kernkonzepte des strategischen DDD-Designs.

Taktisches Design

Um Konzepte in begrenzten Kontexten zu modellieren, verwenden wir das von DDD bereitgestellte taktische Design.

Entität

Zuerst sprechen wir über Entitäten.

Entitäten sind Modelle unabhängiger Dinge in der Domäne. Jede Entität hat eine eindeutige Kennung, wie z. B. ID, UUID, Benutzername usw. In den meisten Fällen ist eine Entität veränderbar und ihr Zustand ändert sich im Laufe der Zeit. Eine Entität muss jedoch nicht unbedingt veränderbar sein.

Das größte Merkmal einer Entität ist ihre Individualität und Einzigartigkeit. Im Kontext eines einfachen Warenkorbs ist die Bestellung beispielsweise eine Entität, die ID ist ihre Kennung und ihr Status kann sich zwischen „aufgegeben“, „bestätigt“ und „erstattet“ ändern.

Wertobjekt

Wertobjekt ist ein Modell, das zur Beschreibung, Quantifizierung oder Messung von Entitäten im Feld verwendet wird. Im Gegensatz zu Entitäten haben Wertobjekte keine eindeutigen Bezeichner und zwei gleichwertige Wertobjekte sind austauschbar. Wertobjekte sind unveränderlich. Nach der Erstellung sind die Eigenschaften eines Wertobjekts endgültig und können nicht geändert werden.

Der direkteste Weg, Wertgegenstände zu verstehen, besteht darin, sich die Banknoten in unserem wirklichen Leben vorzustellen. Im täglichen Leben können die zehn Yuan in RMB von A und die zehn Yuan in RMB von B gleichermaßen umgetauscht werden.

Im obigen Warenkorbkontext ist der Betrag (Geld) ein Wertobjekt, und der Betrag setzt sich aus Währung und Betrag zusammen:

class Money {
  public $currency;
  public $amount;

  function __construct($currency, $amount) {
    $this->currency = $currency;
    $this->amount = $amount;
  }  
}

Die Verwendung von Wertobjekten zur Modellierung kann uns dabei helfen, mithilfe von Code ein Domänenmodell genauer zu erstellen.

Aggregation

Was ist Aggregation? Aggregation ist eine verfeinerte Aufteilung von Geschäftsbereichen im Kontext, und jede Aggregation gewährleistet ihre eigene Geschäftskonsistenz.

Was ist also geschäftliche Unveränderlichkeit? Geschäftsinvarianz stellt eine Geschäftsregel dar, die im Geschäftsbereich nicht verletzt werden kann und deren Konsistenz gewährleistet sein muss. Wenn Sie beispielsweise eine Bestellung zurückerstatten, darf der Rückerstattungsbetrag den gezahlten Betrag nicht überschreiten.

Die Komponenten einer Aggregation sind Entitäten und Wertobjekte, manchmal auch nur Entitäten. Um die Geschäftskonsistenz des Aggregats zu schützen, kann jedes Aggregat nur über eine bestimmte Entität betrieben werden, die als Aggregatstamm bezeichnet wird.

Domänenereignis

Ein Domänenereignis ist ein Ereignis, das über eine gemeinsame Sprache analysiert wird. Im Gegensatz zu herkömmlichen Transaktionsereignissen steht es in engem Zusammenhang mit dem Unternehmen, sodass seine Benennung häufig Geschäftssubstantive enthält und nicht mit der Datenbank verknüpft werden sollte. Wenn Sie beispielsweise Produkte zum Warenkorb hinzufügen, sollte das entsprechende Domänenereignis ProductAddedToCart und nicht CartUpdated lauten.

Zusammenfassung

DDD ​​​​bietet auch taktische Designs wie Application Service und Domain Service. DDD schlägt auch Architekturmuster wie Event Sourcing und Hexagon vor, die wir hier nicht einzeln vorstellen.

Der Kern von DDD besteht darin, ein Modell für Software aus geschäftlicher Sicht zu erstellen. Sein Zweck besteht darin, Code zu erstellen, der näher am Geschäft ist, und Geschäftsprozesse anhand des Codes intuitiver zu verdeutlichen. Das Erkennen von DDD geschieht jedoch nicht an einem Tag. Es erfordert kontinuierliches Üben und kontinuierliches Polieren.

Empfohlenes Lernen: php-Video-Tutorial

Das obige ist der detaillierte Inhalt vonLassen Sie uns über DDD in PHP sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!