Die Verwendung von Anemic und Rich Domains in Symfony

Transcript

1. Die Verwendung von Anemic und Rich Domains in Symfony
2. @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
3. @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?
4. @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
5. @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
6. @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
7. @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
8. @DZunke
9. @DZunke
10. @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
11. @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
12. @DZunke Symfony - The Fast Track
13. @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
14. @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!
15. @DZunke Symfony Form spielt auch mit … Fertig. Das Formular steht zur Verwendung bereit 🍻
16. @DZunke ... aber nicht bei einem Rich Domain Form 😥
17. @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?
18. @DZunke
19. @DZunke Nun haben wir auch unser Rich Domain Objekt
20. @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 ...
21. @DZunke
22. @DZunke
23. @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!
24. @DZunke Und was will uns der Typ jetzt sagen? Leitfaden Lesen 📖 Nachdenken 🤔 Recherchieren & Diskutieren 🤓 Nachdenken 🤔 Entscheiden 🍻
25. @DZunke Danke! Fragen? Mittagspause!