How to map Domain changes on an existing Database
1 like2,351 views
This document discusses mapping an existing database to new domain models when upgrading an e-commerce platform. It proposes using a wrapper layer to interface with legacy data models while building out new domain entity models aligned with Symfony best practices. A migration service would then handle converting data between the legacy and new target databases. Benefits include a cleaner object-oriented design, ability to introduce changes incrementally, and leveraging the mature and well-supported Symfony framework. Challenges include performance impacts and extensive testing needed for the wrapper layer.
How to map Domain changes on an existing Database
- 1. © 2014 OXID eSales AG How To Map Domain Changes On An Existing Database OXID eSales AG Philip Washington Sorst Software Architect
- 2. © 2014 OXID eSales AG An Example: The Article Article id title pic1 pic2 pic3
- 3. position © 2014 OXID eSales AG An Example: The Product id 1 of n Product Picture title path
- 4. Web Frontend REST © 2014 OXID eSales AG Architecture (1) Controller Repositories Presentation Layer Data Layer
- 5. Web Frontend REST © 2014 OXID eSales AG Architecture (2) Controller Domain Services Repositories Presentation Layer Business Logic Layer Data Layer
- 6. ProductController ProductServiceInterface CategoryServiceInterface © 2014 OXID eSales AG The Business Logic Layer ProductService CategoryService DomainEntities DomainEntities Data Layer
- 7. © 2014 OXID eSales AG An Example: The ProductInterface interface ProductInterface { function getId(); function getTitle(); function setTitle($title); function getPictures(); function setPictureAt($position, $path); }
- 8. © 2014 OXID eSales AG An Example: The ProductWrapper class ProductWrapper implements ProductInterface { protected $article; function getId() { $this> article> getId(); } function getPictures() { return array( $this> article> getPic1(), $this> article> getPic2(), $this> article> getPic3()); } ... }
- 9. Business Logic Layer Data Layer queries DomainEntityInterface © 2014 OXID eSales AG The Data Layer Repository DAO Service Mapper DatabaseEntityWrapper DatabaseEntity Row queries maps returns builds queries
- 10. © 2014 OXID eSales AG /** * @ORMTable() * @ORMEntity() */ class Product implements ProductInterface { /** * @ORMColumn(name="id", type="integer") * @ORMId * @ORMGeneratedValue(strategy="AUTO") */ private $id; /** @ORMColumn(name="title", type="string", length=255) */ private $title; /** @ORMOneToMany(targetEntity="Picture", mappedBy="article", cascade={"ALL"}, indexBy="picture") */ private $pictures;
- 11. © 2014 OXID eSales AG Migration MigrationService LegacyRepository DoctrineRepository LegacyDao DomainEntityConverter LegacyDB TargetDB
- 12. © 2014 OXID eSales AG Why we are using Symfony > Open Source > Focus on clean OO Development (DI, Events) > Is more than a web framework > Can be introduced step by step > We don't need to reinvent the wheel, great bundles available > We need to be easily extendable, so building bundles ourself > Mature and well supported > Superior Documentation
- 13. © 2014 OXID eSales AG Discussion: The Cons > Performance might become an issue – But our layered architecture allows us easily cache stuff and build performance optimized services > The wrapping needs much love (=time) to be fully backwards compatible, testing > Of course there are still some modelling limitations imposed
- 14. © 2014 OXID eSales AG Discussion: The Pros > A redefined view on our own domain, built for the future > We don't break things too early > Design flaws can be identified and removed > Things become exchangable, as soon as migration is possible the wrapping will vanish > Implicit migration for the database. Use the wrapper layer to read, use the new domain to write
- 15. © 2014 OXID eSales AG Credits > Icons: – Shmidt Sergey (The Noun Project)
- 16. Thank you for your attention! © 2014 OXID eSales AG OXID eSales AG Bertoldstraße 48 79098 Freiburg GERMANY www.oxid-esales.com E-Mail: info@oxid-esales.com Fon: +49 761 368 89 0
Editor's Notes
- #2: 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
- #3: 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
- #4: 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
- #5: 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
- #6: 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
- #7: 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
- #8: Introduction POPO Wir definieren DomainEntities als Interface Beschreibung dessen WAS sie repräsentieren, aber nicht WIE Art der Repräsentation wird austauschbar
- #9: 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
- #10: 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
- #11: 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
- #12: 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?
- #13: Extendable → Partners
- #14: Gefahr der Überabstrahierung, aber große Domäne
- #15: Kontinuierlicher Prozess
- #17: <number>