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?
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
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
Nachteil: Zeitintensiver im Aufbau, von Beginn an mehr Nachdenken • Nachteil: Die Einarbeitung kann sich komplexer gestalten Nachteile einer Rich Domain
• 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
• 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
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!
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?
• 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 ...
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!
blueswen
vinceamstoutz
naokihaba
youkidearitai
manfredsteyer
kajitack
ioki
nilpe
wemra
ming_ayami
minodriven
16bitidol
rakko
wjessup
kristinabergwall1
twada
jct
axbom
greggifford
sabderemane
mfonobong
eileencodes
inesmontani
tammyeverts
