DE
RU
EN
ES
ZH
FR
PT
AR
HI
Domain-Driven Design in PHP: Wie du aus Chaos Ordnung schaffst
\n\nKennst du das Gefühl, wenn dein PHP-Projekt immer weiter ausufert? Am Anfang ist alles einfach: ein paar Controller, ein Model, ein paar Datenbankabfragen. Und nach einem halben Jahr ertrinkst du in Spaghetti-Code, die Geschäftslogik ist über alle Services verstreut, und eine „einfache“ Änderung einer Anforderung dauert eine Woche.
\n\nKommt dir bekannt vor? Willkommen im Club. Aber es gibt eine gute Nachricht: Domain-Driven Design (DDD) ist keine abstrakte Theorie aus dicken Büchern von Eric Evans. Es ist ein praktisches Werkzeug, das dir wirklich hilft, PHP-Code zu schreiben, den sowohl das Business als auch Entwickler verstehen.
\n\nIn diesem Artikel sehen wir uns DDD in der Praxis an. Ohne theoretisches Geschwafel, mit lebendigen Beispielen in PHP. Du erfährst, wie du DDD in dein Projekt integrierst, ohne dir den Kopf zu zerbrechen oder alles von Grund auf neu zu schreiben. Los geht's!
\n\nWas ist Domain-Driven Design und warum braucht ein PHP-Entwickler es?
\n\nStell dir vor, du entwickelst einen Online-Shop. Es gibt Rabatte, einen Warenkorb, Bestellungen. Die Geschäftslogik lautet: „Rabatt ist nicht mit einem Gutscheincode kombinierbar“, „Eine Bestellung kann nach dem Versand nicht mehr storniert werden“. Wenn du diese Logik in Controllern oder über ORM-Modelle verteilt speicherst, wirst du früher oder später den Überblick verlieren.
\n\nDDD ist ein Ansatz, der die Fachdomäne (deine Geschäftswelt) in den Mittelpunkt der Entwicklung stellt. Anstatt in Tabellen und SQL-Abfragen zu denken, denkst du in Entitäten, Werten und Ereignissen.
\n\nFür PHP ist das besonders relevant. Die Sprache ist flexibel, aber ohne eine klare Architektur werden Projekte schnell zu „Legacy-Code“. DDD bietet ein Gerüst, das auch nach einem Jahr noch lesbar ist.
\n\nStrategisches vs. Taktisches Design
\n\nDDD besteht aus zwei großen Teilen:
\n- \n
- Strategisches Design – das ist die Landkarte deines Projekts. Du identifizierst Bounded Contexts (Abgegrenzte Kontexte) und entwickelst eine Ubiquitäre Sprache (Allgegenwärtige Sprache). Zum Beispiel ist ein Produkt im Kontext „Katalog“ einfach eine Sammlung von Eigenschaften, während es im Kontext „Bestellung“ eine Einheit mit Preis und Menge ist. \n
- Taktisches Design – das sind die Bausteine: Entity, Value Object, Aggregate, Repository, Domain Service, Domain Event. Darauf konzentrieren wir uns. \n
Taktisches Design in PHP: Die Bausteine von DDD
\n\nSchauen wir uns an, wie die grundlegenden DDD-Muster in PHP aussehen. Vergiss ActiveRecord aus Laravel oder Symfony – hier bauen wir ein Modell, das unabhängig vom Framework ist.
\n\n1. Entity (Entität)
\nEine Entität ist ein Objekt mit einer eindeutigen Identität, das sich im Laufe der Zeit verändert. Zum Beispiel User oder Order. Entitäten werden anhand ihrer ID verglichen, nicht anhand ihrer Felder.
<?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Domain\\Entity;\n\nuse App\\Domain\\ValueObject\\UserId;\nuse App\\Domain\\ValueObject\\Email;\n\nclass User\n{\n public function __construct(\n private UserId $id,\n private string $name,\n private Email $email\n ) {}\n\n public function getId(): UserId\n {\n return $this->id;\n }\n\n public function changeEmail(Email $newEmail): void\n {\n // Hier könnte Geschäftslogik stehen: Prüfen, ob die E-Mail bereits vergeben ist\n $this->email = $newEmail;\n }\n\n public function getEmail(): Email\n {\n return $this->email;\n }\n}\n2. Value Object (Wertobjekt)
\nEin Value Object ist ein unveränderliches Objekt, das durch seine Attribute definiert wird, nicht durch eine Identität. Zwei Value Objects sind gleich, wenn alle ihre Felder übereinstimmen. Klassiker: Money, Email, Address.
<?php\n\ndeclare(strict_types=1);\n\nnamespace App\\Domain\\ValueObject;\n\nclass Email\n{\n private string $value;\n\n public function __construct(string $value)\n {\n if (!filter_var($value, FILTER_VALIDATE_EMAIL)) {\n throw new \\InvalidArgumentException('Ungültige E-Mail-Adresse');\n }\n $thi 
