LaraconEU 2016 Recap: DDD Workshop

Dieser Artikel ist in erster Linie für mich selbst. Ich möchte ein paar Schlagworte und Zitate aus dem Workshop die mir besonders im Gedächtnis geblieben sind festhalten. Darüber hinaus ist er vielleicht nützlich für alle die sich für den DDD Workshop interessieren aber unsicher sind ob der Workshop etwas für sie ist. —- Schon letztes Jahr wollte ich einen Workshop bei Mathias Verraes miterleben, konnte dann jedoch im letzten Moment doch nicht teilnehmen. Das hat sich dieses Jahr geändert. Ich konnte im Rahmen einer Laracon EU den 1-Tages Workshop Domain Driven Design in PHP mitmachen. Gespannt habe ich auf der Fahrt nach Amsterdam nochmal das "Blaue Buch" ('Domain Driven Design', Eric Evans, 2004*) ausgepackt und mein Wissen etwas aufgefrischt. Ich wusste nicht so recht was auf mich zukam, da die Workshopbeschreibung sehr allgemein gehalten und auch keine "Mindestanforderungen" aufgelistet waren.

Aus einigen Talks und Interviews habe ich Mathias Verraes als sehr fähigen Speaker in Erinnerung, der sich sehr genau mit der Materie auseinandergesetzt hat.Ausserdem war er mir schon immer sympathisch da er auch einen musikalischen Hintergrund hat und Quereinsteiger in der IT ist ;) Nicht umsonst ist er einer der Mitbegründer der Domain-Driven Design Community in Belgien. Mehr über Ihn auf http://verraes.net/. Aber nun zum Workshop.

Im Prinzip war der Workshop sehr übersichtlich gehalten. Aber was kann man auch schon von einem Tagesworkshop über ein so komplexes Themenfeld auch erwarten. Erste Frage war, wer das "Blaue Buch" gelesen hat. Keine Meldung. Zweite Frage: "Wer hat es halb gelesen?". Nun gingen ein paar Hände hoch, auch meine.

Also war klar - es ist ein Einsteiger-Workshop. Jeder der sich für das Thema interessiert kann damit bedenkenlos teilnehmen. Dennoch ist ein bisschen Grundwissen von Vorteil.

Inhalte des Workshops

Im wesentlichen wurden folgende Begriffe umrissen.

Besonderen Wert hat er dabei auf value objects gelegt. Dazu gab es viel Theorie, einige Beispiele sowie ein Praxis-Beispiel an dem alle Teilnehmer value objects eines simplen Stundenplans finden sollten.

Im nächsten Abschnitt des Artikels beschreibe ich einige Schlagworte die mir so hängen geblieben sind.

complexity

„make it explicit“

Mit DDD möchte man die Komplexität in Software strukturieren. Komplexe Probleme erfordern komplexe Lösungen, sonst wären sie nicht komplex. Komplexe Probleme können somit keine einfache Lösung haben. Man möchte die Komplexität nicht verstecken. Man macht sie offensichtlich. Wie alle großen Probleme versucht man sie zu strukturieren und in kleine Abschnitte zusammen fassen.

Value Objects

Value Objects sind Objekte die durch ihren Inhalt definiert sind und nicht über eine separate ID identifiziert werden. Ein Beispiel ist das Money Object.

$moneyOfJack = new Money(5, “EUR“);
$moneyOfJane = new Money(5, “EUR“);
$moneyOfJack == $moneyOfJane; // true
$moneyOfJack === $moneyOfJane; // false

Anders wäre es wenn Jack genau denselben 5 Euro Schein an Jane übergibt.

$moneyOfJack = new Money(5, “EUR“);
$moneyOfJane = $moneyOfJack;
$moneyOfJack == $moneyOfJane; // true
$moneyOfJack === $moneyOfJane; // true

Während hingegen zwei Person die zwar denselben Namen haben logischerweise trotzdem nicht dieselbe Person sind.

Value Obects sind immutable (=nicht änderbar). Es gibt bei der Implementation keine Setter. Value Objects werden über den Constructor instantiiert.

In diesem Workshop ging es ganz viel um das Thema Value Objects. Im Praxisbeispiel hat er einen einfachen Stundenplan auf das Whiteboard gemalt und wir sollten herausfinden welche Value Objects vorhanden sind. Das Resultat war, dass fast jedes Element, sowie Gruppierungen einzelner Elemente bzw. Value Objects weitere Value Objects sind. Aufgrund des fehlenden Kontexts war eine genauere Bestimmung nicht möglich. Würde man das Modell in Kontext setzen, würden einige der gefundenen Value Objects als Entities betrachtet werden.

Domain

„Talk to the domain experts“

Als ich mich zum ersten mal mit der Materie beschäftigt hatte, bin ich nicht dahinter gestiegen was nun mit domain, domain logic, business logic gemeint ist. Es handelt sich dabei um das Wissensgebiet eines Arbeitsbereiches - sehr umständlich ausgedrückt. Besser ein Beispiel: Wenn man eine Software im Bereich Bankenwesen entwickeln soll, muss man sich in diesem Fachbereich auskennen. Da man in erster Linie Softwareentwickler ist, benötigt man sogenannte domain experts die sich im Bankenwesen besser auskennen. Mit diesen domain experts versucht man nun die Problee zu identifizieren und Lösungen zu etwickeln.

Ubiquitous language

“Language are words, grammar, phrases, …“

Unter ubiquitous language versteht man eine vereinheitlichte Sprache zwischen Entwickler und domain experts. Als Entwickler verwendet man oft sehr technische Begriffe um etwas zu beschreiben. Ein Mitarbeiter aus der Branche (z.B. das oben genannte Bankwesen) versteht solche Begriffe nicht - anders herum genauso. Es gilt also die Sprache auf einen gemeinsamen Nenner zu bringen, der die Business-Vorfälle genau beschreibt. Beispiel: Als Autovermieter hat man eine ganze Flotte an Autos. So hätte man vielleicht ein cars oder fleet Repository. Kommt ein neues Auto zu Flotte hinzu, würde man als Developer vielleicht die Methode createCar oder addCar implementieren. In dieser Branche nennt man sowas aber inFleeting. Somit würde man eher diesen Begriff zur ubiquitous language hinzufügen und den Quelltext mit der ubiquitous language beschreiben.

Repositories

Ein Repository ist in erster Linie eine „Collection of Things“. Dabei sind Repositories „persistent orientated“ oder „domain or collection orientated“.

Aggregates

Dieser Punkt wurde im Workshop auch kurz angerissen. Ein Aggregate bezeichnet ein abgeschlossene Einheit verschiedener Objekte. Beispiel: Model Order und Model LineItem. Ein Order hat mehrere LineItems. Es bildet ein Aggregate. Order dient als Aggregate "root". Andere Teile des Systems müssen mit dem Aggreagate-Root (Order) kommunizieren, um LineItems ändern zu können. Es darf somit niemand direkt LineItems verändern oder ansprechen. Eine "boundary" grenzt dieses System vom Rest ab.

Boundaries

"Boundaries" oder "Bounded Contexts" bezeichnet eine natürliche Abgrenzung eines Domain Models oder Teilsystem zum restlichen System. Das ist besonders dann wichtig um sich auf ein Problem zu konzentrieren, ohne die Komplexität des "großen Ganzen" berücksichtigen zu müssen. Bounded Context kann auch folgendes sein: z.B. ein Account ist bei einer Bank etwas ganz anderes als bei einer Bücherei. Es kommt also immer auf den Kontext an.

Fazit

Alles in allem hat mir der Workshop sehr gut gefallen. Es war ein guter Einstieg in die Thematik "Domain Driven Design". Das Thema ist wahnsinnig komplex und umfassend, gerade wenn man erst beginnt sich damit auseinander zu setzen. Allen Teilnehmern rauchten am Ende des Tages die Köpfe. Mathias Verraes lies immer wieder Beispiele und Anekdoten aus eigenen Erfahrungen mit seinen Kunden und Domains einfließen, was etwas den praktischen Bezug zu all den abstrakten Beispielen herstellte.

Der Workshop hat definitiv Lust auf mehr gemacht - so kam mir persönlich der praktische Teil etwas zu kurz, da ich einiges schon aus dem DDD Buch von Eric Evans wusste. Dadurch fehlte natürlich auch der Bezug zu PHP. Ich hätte mir z.B. einen Beispiel-Code einer einfachen Value Objects Implementation und deren Verwendung gewünscht. Er hat zwar eine Implemetation des Money Value Objects auf dem Whiteboard skizziert, jedoch hätte mich interessiert wie ich dieses Objekt nun im eigenen Code verwende. Die Zeit hat jedoch dafür nicht mehr gereicht - daher überlege ich mir nun irgendwann den 3 Tages Workshop zu besuchen :)