Verweis Gigi: Domain Driven Design → Technik
Vorstellung von Ideen und Konzepten in SoftwareArchitektur und Datenbankmodellierung
Wir haben die Chance, weil die existierende Domäne sehr vollständig ist
Geringe Komplexität der Beispiele
Work in progress
Von dem erwähnten Artikel Beispiel ausgehend
Domäne in DB abgebildet → ER
Kurz (Domain)Entität definieren
Angenommen wir haben drei Bilder an einem Artikel nicht normalisiert wegen begrenzter Anzeigemöglichkeiten und “Performance”
Prämisse: Datenbank darf nicht verändert! werden
Modellierung des Produkts, anderer Name, ein Produkt ist quasi “nichts” außer einer id (im Beispiel noch mit title, auch das kann man rausextrahieren)
Die Bilder sollen getrennt sein, sind quasi nur für die Präsentation da
Modellierung als “weak entity” als Beispiel, Komplexität beliebig erhöhbar
Die Thematik des Vortrags ist: Wie nutze ich eine Datenbank, die wie das erste Beispiel organisiert ist, aber das zweite Beispiel repräsentieren soll
Simpelstes Symfony Beispiel
Controller laufen direkt gegen DB, gut für kleine Seiten, ein paar versteckte “Services”
Was wir wollen, dünne Controller, klare Schnittstellen
Wir benutzen dedizierten Business Logic Layer
Trennen Datenbank von Presentation
Data Layer muss austauschbar sein
Business Logic Layer als Definition der unterstützten Domänenoperationen, Workflows
Schichtenarchitektur bedeutet auch, keine Schicht darf übersprungen werden
Durch Interfaces definiert
Spezifizieren die API → müssen stabil bleiben
Wer seine Domäne nicht schützt hat keine Chance auf Versionierung → Partner
Sind der einzige Platz in der Business Logik (Workflows) stattfinden, nicht Controller, nicht Data Layer
Verarbeiten Domänenobjekte
Dependency Injection bietet Flexibilität (Erweiterbarkeit, Customizability), Crucial
Beispiel: ElasticSearch
Die Frage: wie definieren wir DomänenObjekte
Introduction POPO
Wir definieren DomainEntities als Interface
Beschreibung dessen WAS sie repräsentieren, aber nicht WIE
Art der Repräsentation wird austauschbar
Beispiel für das WIE
Verhalten bleibt nach außen konsistent
Wrapping ist eine Möglichkeit, es ist auch möglich mit Transformation zu arbeiten
Wie kommen wir von der Datenbank zur Domäne
DAO (erklären, DBAL) fragt DB, bekommt Row
Wir wollen DatabaseEntity (teilweise angebasst) => custom Mapping
Warum kein ORM? Bei uns nicht machbar
Zugriff auf die Datenbank NUR über DAO
Von da zum DomainEntity:
Repository exposed Datenzugriff transparent nach außen
Transformationen finden im Repository statt, kann beliebig komplex sein
Vergleiche ORM Repository
Idealerweise lässt sich unsere Domäne in einer relationalen Datenbank repräsentieren
(Sauberes) ORM lässt sich umsetzen, POPO
Repository lässt sich ersetzen, Overhead fällt weg
Nebeneffekt: Es lässt sich Datenbank Migration durchführen
Wir haben die Möglichkeit über unseren Adapter Layer die “legacy” DB als neues DomainEntity zu lesen
Übersetzen in ORM Implementierung
Speichern über neues Repository
Könnten Upgrade Pfad anbieten
Warum keine Doctrine Schema Migration?