© Ron Dale/Shutterstock.com
JavaScript Kompendium
Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen

TypeScript domänenspezifisch nutzen?

TypeScript-Sprachkonstrukte ermöglichen es, mit überschaubarem Aufwand einen modellgetriebenen Ansatz aus folgenden Elementen zu etablieren: einem Domänenmodell, einem daraus erzeugten maschinenlesbaren Schema und einer pragmatischen, hierarchischen Query Language.

Thomas Mahringer


Artikelserie Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen Teil 2: Mit TypeScript Union Types die Grammatik für eine hierarchische QL definieren Teil 3: Abfragen am Server generisch gegen eine relationale DB mappen und am Client typsicher verarbeiten Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauenTeil 2: Mit TypeScript Union Types die Grammatik für eine hierarchische QL definierenTeil 3: Abfragen am Server generisch gegen eine relationale DB mappen und am Client typsicher verarbeitenWissensmanagement oder Enterprise Relationship ManagementLassen Sie uns mit einem Beispiel aus der Praxis starten: In einem System, in dem es grob gesagt um das effiziente Verwalten und Wiederauffinden von Wissen oder Enterprise Relationship Management im weitesten Sinne geht, wird eine Vielzahl von Objekten logisch in einer netzwerkartigen Struktur gespeichert (Abb. 1).Die physische Speicherung soll jetzt noch nicht relevant sein, sondern nur, dass die Objekte sehr stark miteinander vernetzt sind: Personen, Kunden, Lieferanten, Verträge, Angebote, Mails, Projekte, Teilprojekte, Telefonate, Ressourcen, Aufgaben, Termine, Mitarbeiter und viele mehr. Schaut man sich das Ganze aus einer Domain-driven-Design-Sicht an, fällt schnell auf, dass sich keine klare hierarchische Struktur oder Aggregate Root finden lässt. Je nachdem, wer in welcher Rolle und welchem Anwendungsfall darauf sieht, ergeben sich beliebig viele Einstiegspunkte in das Beziehungsnetzwerk. Ein Projektleiter wird z. B. vorrangig über das Projekt einsteigen und will von dort aus möglichst schnell die zugehörigen Informationen finden. Ein Vertriebsmitarbeiter ist dagegen fast ausschließlich an der Sicht auf seine Kunden interessiert.Das Grundproblem: Endpoint Mania, Data Overfetching und UnderfetchingWie man sich leicht vorstellen kann, ist nicht nur die endanwenderfreundliche User Experience eine Herausforderung, sondern auch, wie man die Datenabfragen möglichst effizient gestaltet. Abbildung 2 zeigt einen naiven Ansatz: Von einem REST-Endpunkt wird zunächst „meine Kunden“ (eine Liste mit den IDs und Grunddaten der Kunden) geladen, danach werden die für den jeweiligen Screen relevanten Daten jeweils wieder über einen REST-Endpunkt geladen: die Anzahl der Einkäufe des Kunden, seine Stars (Bewertungen) usw.Abb. 2: Ein naiver Ansatz, der N+1 Roundtrips verursachtDieser naive Ansatz ist zur Laufzeit natürlich nicht haltbar: Wir verursachen N+1 R...

JavaScript Kompendium
Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen

TypeScript domänenspezifisch nutzen?

TypeScript-Sprachkonstrukte ermöglichen es, mit überschaubarem Aufwand einen modellgetriebenen Ansatz aus folgenden Elementen zu etablieren: einem Domänenmodell, einem daraus erzeugten maschinenlesbaren Schema und einer pragmatischen, hierarchischen Query Language.

Thomas Mahringer


Artikelserie Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauen Teil 2: Mit TypeScript Union Types die Grammatik für eine hierarchische QL definieren Teil 3: Abfragen am Server generisch gegen eine relationale DB mappen und am Client typsicher verarbeiten Teil 1: Mit TypeScript Metadata und Reflection ein Domänenmodell aufbauenTeil 2: Mit TypeScript Union Types die Grammatik für eine hierarchische QL definierenTeil 3: Abfragen am Server generisch gegen eine relationale DB mappen und am Client typsicher verarbeitenWissensmanagement oder Enterprise Relationship ManagementLassen Sie uns mit einem Beispiel aus der Praxis starten: In einem System, in dem es grob gesagt um das effiziente Verwalten und Wiederauffinden von Wissen oder Enterprise Relationship Management im weitesten Sinne geht, wird eine Vielzahl von Objekten logisch in einer netzwerkartigen Struktur gespeichert (Abb. 1).Die physische Speicherung soll jetzt noch nicht relevant sein, sondern nur, dass die Objekte sehr stark miteinander vernetzt sind: Personen, Kunden, Lieferanten, Verträge, Angebote, Mails, Projekte, Teilprojekte, Telefonate, Ressourcen, Aufgaben, Termine, Mitarbeiter und viele mehr. Schaut man sich das Ganze aus einer Domain-driven-Design-Sicht an, fällt schnell auf, dass sich keine klare hierarchische Struktur oder Aggregate Root finden lässt. Je nachdem, wer in welcher Rolle und welchem Anwendungsfall darauf sieht, ergeben sich beliebig viele Einstiegspunkte in das Beziehungsnetzwerk. Ein Projektleiter wird z. B. vorrangig über das Projekt einsteigen und will von dort aus möglichst schnell die zugehörigen Informationen finden. Ein Vertriebsmitarbeiter ist dagegen fast ausschließlich an der Sicht auf seine Kunden interessiert.Das Grundproblem: Endpoint Mania, Data Overfetching und UnderfetchingWie man sich leicht vorstellen kann, ist nicht nur die endanwenderfreundliche User Experience eine Herausforderung, sondern auch, wie man die Datenabfragen möglichst effizient gestaltet. Abbildung 2 zeigt einen naiven Ansatz: Von einem REST-Endpunkt wird zunächst „meine Kunden“ (eine Liste mit den IDs und Grunddaten der Kunden) geladen, danach werden die für den jeweiligen Screen relevanten Daten jeweils wieder über einen REST-Endpunkt geladen: die Anzahl der Einkäufe des Kunden, seine Stars (Bewertungen) usw.Abb. 2: Ein naiver Ansatz, der N+1 Roundtrips verursachtDieser naive Ansatz ist zur Laufzeit natürlich nicht haltbar: Wir verursachen N+1 R...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang