Slide 1

Slide 1 text

Die Verwendung von Anemic und Rich Domains in Symfony

Slide 2

Slide 2 text

@DZunke • Quentic GmbH • Leidenschaftlicher Backend-Entwickler • Langstrecken-Bio-Biker 🚴‍♂️ • Hertha -Fan und -Mitarbeiter (Das Leid hilft! 🙈) • Intuitiver Langbogenschütze 🏹 That‘s me, Denis (Der Andere)! • Notorischer Klugscheißer mit Übernahme-Tendenzen

Slide 3

Slide 3 text

@DZunke • Was sind Anemic und Rich Domain? • Welchen dieser Ansätze verfolgt das Symfony Framework? • Kann man die Art der Domain eigentlich wählen? • Was können wir für einen Schluss daraus ziehen? Über was reden wir?

Slide 4

Slide 4 text

@DZunke Was ist eigentlich eine Anemic Domain? • Eine Domain, die kaum bis keine Business Logik enthält • Im Kern ist die Anemic Domain eine Sammlung DTOs • Setter und Getter überall – mehr braucht es nicht

Slide 5

Slide 5 text

@DZunke • Vorteil: Schnell aufgebaut durch einfache Klassen / Generatoren • Vorteil: Es braucht kein komplexes Daten-Mapping zur Datenbank • Vorteil: Einfach zu verwenden in Applikationen Vorteile einer Anemic Domain

Slide 6

Slide 6 text

@DZunke • Nachteil: Keinen validen Status über die Laufzeit – kein Verlass drauf • Nachteil: In der Regel übers ganze System verteilte Business-Logik • Nachteil: Keine Sicherheit sie richtig zu verwenden • Nachteil: Risiko von doppelter Programmierung bei großer Codebase • Nachteil: Für ein sinnvolles Testing braucht es Abhängigkeiten Nachteile einer Anemic Domain

Slide 7

Slide 7 text

@DZunke Was ist eigentlich eine Rich Domain? • Eine Domain, die viel bis jegliche Business Logik enthält • Validierungen finden in der Domain statt • Nicht jedes Property muss öffentlich zugänglich sein • Methoden haben einen sinnhaften Namen • Methoden können auch mit mehreren Argumenten arbeiten • In der Regel keine einfach benannten Setter • Zusätzliche Logik kann enthalten sein – z.B. ein lokaler Event-Storage

Slide 8

Slide 8 text

@DZunke

Slide 9

Slide 9 text

@DZunke

Slide 10

Slide 10 text

@DZunke • Nachteil: Die Komplexität kann die Lesbarkeit einschränken • Nachteil: Zeitintensiver im Aufbau, von Beginn an mehr Nachdenken • Nachteil: Die Einarbeitung kann sich komplexer gestalten Nachteile einer Rich Domain

Slide 11

Slide 11 text

@DZunke • Vorteil: Nachvollziehbar wie die Domain verwendet werden will • Vorteil: Daten und Verhalten sind an einer Stelle • Vorteil: Die Domain selbst erzwingt einen stetig validen Status • Vorteil: Die Business Logik wird leichter transportabel / wiederverwendbar • Vorteil: Tests schreiben ergibt einen Sinn! Vorteile einer Rich Domain

Slide 12

Slide 12 text

@DZunke Symfony - The Fast Track

Slide 13

Slide 13 text

@DZunke Eine ganz normale Symfony Domain • Ein besonderer Mittelweg • Doctrine Entitäten repräsentieren die Domain • Constraints unterstützen Domain Logik • Eine Entität hat zur Laufzeit einen invaliden Status, kann aber geprüft werden Eine süß gezuckerte Anemic Domain

Slide 14

Slide 14 text

@DZunke Doch kann Doctrine viel mehr, oder? • Komplexe Konstruktoren sind Doctrine egal, sie werden umgangen • Methoden sind egal – Direkter Zugriff auf Properties einer Klasse • Embeddables erlauben Klassenstrukturen ohne zusätzliche Tabellen • Das Festlegen eigener „Typen“ erlaubt weitere Komplexität auf Spalten • Beispiel: Value Objekte auf Datenbank-JSON-Objekte mappen • Trennung Doctrine / Domain durch XML Konfigurationen Eine Rich Domain wäre möglich!

Slide 15

Slide 15 text

@DZunke Symfony Form spielt auch mit … Fertig. Das Formular steht zur Verwendung bereit 🍻

Slide 16

Slide 16 text

@DZunke ... aber nicht bei einem Rich Domain Form 😥

Slide 17

Slide 17 text

@DZunke • Man muss ein Formular nicht an eine Entität binden • Jedes Formular bekommt ein passendes Objekt? • CQRS? Symfony Messenger! • Die Domain Aktionen werden auch noch wiederverwendbar! Da lässt sich doch bestimmt was tun?

Slide 18

Slide 18 text

@DZunke

Slide 19

Slide 19 text

@DZunke Nun haben wir auch unser Rich Domain Objekt

Slide 20

Slide 20 text

@DZunke • Symfony Forms unterstützt das bauen eigener Data Mapper • Mit diesen kann man die Setter / Getter Logik überschreiben • Unterstützt so auch mehrere Argumente für einzelne Methoden • Wäre auch nützlich für große Formulare im Symfony Messenger Ansatz • Ein Array aus Messages als Rückgabe des Formulares nach der Verarbeitung Da geht noch was ...

Slide 21

Slide 21 text

@DZunke

Slide 22

Slide 22 text

@DZunke

Slide 23

Slide 23 text

@DZunke • Symfonys RAD Ansatz ist in Sachen Domain nicht kompatibel • Die Dokumentation ist generell nicht auf eine reine Rich Domain ausgelegt • Die Maker können die Rich Domain auch nicht erahnen (Noch nicht?) • Um das mehr an Code für eine Rich Domain kommt man nicht herum Und wie sieht es nun mit dem RAD-Ansatz aus? Fazit: Symfony Maker als RAD Angebot ist nicht geeignet für eine Rich Domain! ABER: Symfony Maker als RAD Angebot ist geeignet zur Unterstützung!

Slide 24

Slide 24 text

@DZunke Und was will uns der Typ jetzt sagen? Leitfaden Lesen 📖 Nachdenken 🤔 Recherchieren & Diskutieren 🤓 Nachdenken 🤔 Entscheiden 🍻

Slide 25

Slide 25 text

@DZunke Danke! Fragen? Mittagspause!