Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Die Verwendung von Anemic und Rich Domains in S...

Die Verwendung von Anemic und Rich Domains in Symfony

Denis Zunke

October 06, 2023
Tweet

Other Decks in Programming

Transcript

  1. @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
  2. @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?
  3. @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
  4. @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
  5. @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
  6. @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
  7. @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
  8. @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
  9. @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
  10. @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!
  11. @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?
  12. @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 ...
  13. @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!
  14. @DZunke Und was will uns der Typ jetzt sagen? Leitfaden

    Lesen 📖 Nachdenken 🤔 Recherchieren & Diskutieren 🤓 Nachdenken 🤔 Entscheiden 🍻