Best Practice- oder Entwurfsmuster zum Abrufen von Daten für Berichte und Dashboards in einer domänenreichen Anwendung

Zunächst möchte ich sagen, dass dies eine vernachlässigte Frage / ein vernachlässigter Bereich zu sein scheint. Wenn diese Frage also verbessert werden muss, hilf mir, diese Frage zu einer großartigen Frage zu machen, von der andere profitieren können! Ich suche Rat und Hilfe von Leuten, die Lösungen implementiert haben, die dieses Problem lösen, und nicht nur Ideen zum Ausprobieren.

Nach meiner Erfahrung gibt es zwei Seiten einer Anwendung - die "Task" -Seite, die größtenteils domänengesteuert ist und auf der die Benutzer intensiv mit dem Domänenmodell (der "Engine" der Anwendung) interagieren, und die Berichterstellungsseite, auf der die Benutzer Erhalten Sie Daten basierend darauf, was auf der Aufgabenseite passiert.

Auf der Aufgabenseite ist klar, dass eine Anwendung mit einem umfangreichen Domänenmodell über Geschäftslogik im Domänenmodell verfügen und die Datenbank hauptsächlich aus Gründen der Persistenz verwendet werden sollte. Trennung von Bedenken, jedes Buch ist darüber geschrieben, wir wissen, was zu tun ist, genial.

Was ist mit der Berichtsseite? Sind Data Warehouses akzeptabel oder haben sie ein schlechtes Design, weil sie Geschäftslogik in die Datenbank und in die Daten selbst integrieren? Um die Daten aus der Datenbank in Data Warehouse-Daten zu aggregieren, müssen Sie Geschäftslogik und Regeln auf die Daten angewendet haben. Diese Logik und Regeln stammen nicht aus Ihrem Domänenmodell, sondern aus Ihren Datenaggregationsprozessen. Ist das falsch?

Ich arbeite an großen Finanz- und Projektmanagementanwendungen, bei denen die Geschäftslogik umfangreich ist. Wenn ich über diese Daten berichte, habe ich oft eine Menge Aggregationen zu erledigen, um die für den Bericht / das Dashboard erforderlichen Informationen abzurufen, und die Aggregationen enthalten eine Menge Geschäftslogik. Aus Gründen der Leistung habe ich es mit stark aggregierten Tabellen und gespeicherten Prozeduren gemacht.

Angenommen, Sie benötigen einen Bericht / ein Dashboard, um eine Liste der aktiven Projekte anzuzeigen (stellen Sie sich 10.000 Projekte vor). Jedes Projekt benötigt eine Reihe von Metriken, die damit angezeigt werden, zum Beispiel:

1. Gesamtbudget; Gesamtetat
2. Aufwand bis heute
3. Verbrennungsrate
4. Budget Erschöpfungstermin bei aktueller Brennrate
5. usw.

Jedes davon beinhaltet eine Menge Geschäftslogik. Und ich spreche nicht nur von der Multiplikation von Zahlen oder einer einfachen Logik. Ich spreche davon, um das Budget zu erhalten, müssen Sie ein Tarifblatt mit 500 verschiedenen Tarifen anwenden, einen für die Zeit jedes Mitarbeiters (bei einigen Projekten haben die anderen einen Multiplikator), Ausgaben und einen angemessenen Aufschlag usw. Logik ist umfangreich. Das Aggregieren und Optimieren von Abfragen erforderte eine Menge Zeit, um diese Daten für den Client in angemessener Zeit zu erhalten.

Sollte dies zuerst über die Domain ausgeführt werden? Was ist mit der Leistung? Selbst bei reinen SQL-Abfragen erhalte ich diese Daten kaum schnell genug, damit der Client sie in angemessener Zeit anzeigt. Ich kann mir nicht vorstellen, diese Daten schnell genug an den Client zu senden, wenn ich all diese Domänenobjekte rehydriere und ihre Daten in der Anwendungsebene mische und abgleiche und aggregiere oder versuche, die Daten in der Anwendung zu aggregieren.

In diesen Fällen scheint SQL gut darin zu sein, Daten zu verarbeiten, und warum nicht? Dann haben Sie jedoch Geschäftslogik außerhalb Ihres Domain-Modells. Jede Änderung an der Geschäftslogik muss in Ihrem Domänenmodell und Ihren Berichtsaggregationsschemata geändert werden.

Ich bin wirklich ratlos, wie der Berichterstellungs- / Dashboard-Teil einer Anwendung in Bezug auf domänenbasiertes Design und bewährte Methoden gestaltet werden soll.

Ich habe das MVC-Tag hinzugefügt, weil MVC das Design-Flavor du Jour ist und ich es in meinem aktuellen Design verwende, kann aber nicht herausfinden, wie die Berichtsdaten in diese Art von Anwendung passen.

Ich suche Hilfe in diesem Bereich - Bücher, Designmuster, Schlüsselwörter zu Google, Artikel, alles. Ich kann zu diesem Thema keine Informationen finden.

EDIT UND EIN ANDERES BEISPIEL

Ein weiteres perfektes Beispiel, dem ich heute begegnet bin. Der Kunde möchte einen Bericht für das Customer Sales Team. Sie wollen eine einfache Metrik:

Wie hoch ist der aktuelle Jahresumsatz jedes Vertriebsmitarbeiters?

Das ist aber kompliziert. Jeder Verkäufer nahm an mehreren Verkaufschancen teil. Einige haben sie gewonnen, andere nicht. In jeder Verkaufschance gibt es mehrere Vertriebsmitarbeiter, denen je nach Rolle und Teilnahme ein Prozentsatz der Gutschrift für den Verkauf zugewiesen wird. Stellen Sie sich nun vor, Sie gehen die Domain durch ... die Menge an Objekt-Rehydration, die Sie durchführen müssten, um diese Daten für jeden Vertriebsmitarbeiter aus der Datenbank abzurufen:

Holen Sie sich alle SalesPeople->
Für jeden erhalten Sie ihre SalesOpportunities->
Für jeden erhalten Sie ihren Prozentsatz des Verkaufs und berechnen Sie ihre Verkaufsmenge
dann Addieren Sie alle ihre SalesOpportunityVerkaufsmenge.

Und das ist EINE Metrik. Sie können auch eine SQL-Abfrage schreiben, die schnell und effizient ausgeführt und auf Schnelligkeit eingestellt werden kann.

EDIT 2 - CQRS-Muster

Ich habe über das CQRS-Muster gelesen, und obwohl es faszinierend ist, sagt sogar Martin Fowler, dass es nicht getestet wurde. Wie wurde dieses Problem in der Vergangenheit gelöst? Dies muss irgendwann von jedem erlebt worden sein. Was ist ein etablierter oder abgenutzter Ansatz mit Erfolgsbilanz?

Bearbeiten 3 - Berichtssysteme / Tools

In diesem Zusammenhang sind auch Berichterstellungstools zu berücksichtigen. Reporting Services / Crystal Reports, Analysis Services und Cognoscenti usw. erwarten alle Daten von SQL / Datenbank. Ich bezweifle, dass Ihre Daten später in Ihrem Unternehmen eingehen. Und doch sind sie und andere wie sie ein wesentlicher Bestandteil der Berichterstattung in vielen großen Systemen. Wie werden die Daten für diese Systeme richtig gehandhabt, wenn in der Datenquelle für diese Systeme und möglicherweise in den Berichten selbst sogar Geschäftslogik vorhanden ist?

Dies ist eine sehr glatte Antwort, aber um es auf den Punkt zu bringen:

In Bezug auf DDD wird die Berichterstellung möglicherweise als eingeschränkter Kontext betrachtet. Sie sollten also eher bereit sein zu glauben, dass es in Ordnung ist, mehr als ein Modell zu haben, als in Bezug auf "DAS" Domänenmodell. Ja, es ist in Ordnung, wenn die Berichtsdomäne Berichtsgeschäftslogik enthält, genauso wie es in Ordnung ist, wenn die Transaktionsdomäne Transaktionsgeschäftslogik enthält.

In Bezug auf die Frage von beispielsweise gespeicherten SQL-Prozeduren im Vergleich zum Domänenmodell im Anwendungscode gelten für das Berichtssystem dieselben Vor- und Nachteile wie für das Transaktionssystem.

Da ich sehe, dass Sie der Frage ein Kopfgeld hinzugefügt haben, habe ich die Frage erneut gelesen und festgestellt, dass Sie nach einer bestimmten Ressource für diese Frage fragen. Ich dachte, ich beginne mit dem Vorschlag, dass Sie sich andere Fragen zum Stapelüberlauf zu diesem Thema ansehen. und ich fand dieses https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

Im Allgemeinen besteht das Ziel darin, CQRS als Muster für Ihr System zu verwenden, das mit DDD konsistent ist, und sich auf die Verantwortlichkeiten der Abfrageseite zu verlassen, um die Berichterstellung zu erledigen, aber ich bin nicht sicher, ob dies eine hilfreiche Antwort ist dein Fall.

Ich habe auch diese http://www.martinfowler.com/bliki/ReportingDatabase.html gefunden , die ich hier verlinkt habe: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

Hier ist ein interessanter Artikel von ACM zu diesem Thema: http://dl.acm.org/citation.cfm?id=2064685, der sich jedoch hinter einer Paywall befindet, sodass ich ihn nicht lesen kann (kein ACM-Mitglied :().

Es gibt auch diese hier Antwort auf eine ähnliche Frage: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

und dieses hier: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

Hoffe das hilft!

Mein Verständnis aus Ihrer Frage lautet: Bewerbung für die tägliche Aufgabe hat

Ansicht >> Steuerung >> Modell (BL) >> Datenbank (Daten)

Anwendung für Meldezwecke

Ansicht >> Controller >> Modell >> Datenbank (Daten + BL)

Daher führt eine Änderung der BL für die Aufgabenanwendung auch zu einer Änderung der BL für die Berichterstellung . Das ist dein wirkliches Problem, oder? Nun, das ist in Ordnung, wenn du zweimal Änderungen vornimmst. Diesen Schmerz musst du trotzdem ertragen. Der Grund ist, dass beide BLs durch ihre jeweiligen Bedenken getrennt sind. Eine dient zum Abrufen von Daten und eine zum Zusammenfassen von Daten. Außerdem werden Ihre ursprüngliche BL und die aggregierende BL in einer anderen Technologie oder Sprache ( C # / Java und SQL Proc ) geschrieben. Es gibt kein Entrinnen.

Nehmen wir ein weiteres Beispiel, das sich nicht speziell auf die Berichterstattung bezieht. Angenommen, eine Firma XXX verfolgt Mails aller Nutzer zur Interpretation und verkauft diese Informationen an Marketingfirmen. Jetzt wird es eine BL für die Interpretation und eine BL für die Aggregation von Daten für Marketingunternehmen geben. Die Bedenken sind bei beiden BL unterschiedlich. Morgen, wenn sich ihre BL so ändert, dass aus Kuba kommende Mails ignoriert werden sollten, wird die Geschäftslogik auf beiden Seiten geändert.

Berichterstellung ist ein begrenzter Kontext oder eine Unterdomäne, um es locker auszudrücken. Es löst die geschäftliche Anforderung, Daten zu sammeln, zu aggregieren und zu verarbeiten, um Business Intelligence zu erhalten.

Wie Sie diese Unterdomäne implementieren, hängt wahrscheinlich von der (meist) richtigen Art und Weise ab, wie Sie dies tun können, und davon, was Ihre Infrastruktur zulässt. Ich beginne gerne auf der ersteren Seite und bewege mich nur bei Bedarf auf die letztere zu.

Sie können dies wahrscheinlich in zwei Hauptprobleme aufteilen, die Sie lösen:

1. Aggregieren oder Speichern von Daten. Dies sollte eine Datenquelle verarbeiten und die Informationen so kombinieren, dass sie in einer anderen Datenquelle gespeichert werden.

2. Abfragen der aggregierten Datenquelle zur Bereitstellung von Business Intelligence.

Keines dieser Probleme bezieht sich auf eine bestimmte Datenbank oder Speicher-Engine. Ihre Domänenschicht sollte sich nur mit Schnittstellen befassen, die von verschiedenen Speicheradaptern in Ihrer Infrastrukturschicht implementiert werden.

Möglicherweise haben Sie verschiedene Mitarbeiter oder einen geplanten Auftrag ausgeführt, der in einige bewegliche Teile unterteilt ist:

• Etwas abzufragen
• Etwas zu aggregieren
• Etwas zu speichern

Hoffentlich können Sie dort einige der CQRS durchscheinen sehen.

Auf der Berichtsseite sollte nur eine Abfrage erforderlich sein, jedoch niemals eine direkte Eingabe in die Datenbank. Sehen Sie sich hier Ihre Schnittstellen und Ihre Domain-Schicht an. Dies ist nicht die gleiche Problemdomäne wie Ihre primären Aufgaben, aber hier sollte noch eine Logik vorhanden sein, an die Sie sich halten möchten.

Sobald Sie direkt in die Datenbank eintauchen, sind Sie stärker darauf angewiesen, und es kann möglicherweise zu Beeinträchtigungen der Datenanforderungen Ihrer ursprünglichen Anwendung kommen.

Außerdem bevorzuge ich es definitiv, Tests zu schreiben und Code zu entwickeln, anstatt Abfragen oder gespeicherte Prozeduren. Ich mag es auch, mich erst dann an bestimmte Werkzeuge zu binden, wenn dies absolut notwendig ist.

Das Abrufen großer Informationsmengen über WANs, einschließlich des Internets, ist problematisch, da die Antwortzeiten verzögert sind, kein direkter Speicherzugriff auf die Ressourcen für die Datenbereitstellung besteht und keine Fehlertoleranz besteht.

Diese Frage beschreibt ein Entwurfsmuster zur Lösung der Probleme bei der Verarbeitung von Ergebnissen aus Abfragen, die große Datenmengen zurückgeben. In der Regel werden diese Abfragen von einem Client-Prozess über ein Wide Area Network (oder Internet) mit einer oder mehreren mittleren Ebenen an eine relationale Datenbank auf einem Remoteserver gestellt.

Die Lösung umfasst die Implementierung einer Kombination von Datenabrufstrategien, einschließlich der Verwendung von Iteratoren für das Durchlaufen von Datensätzen und die Bereitstellung einer angemessenen Abstraktionsebene für den Client, die doppelte Pufferung von Datenteilmengen, das Abrufen von Multithread-Daten und das Aufteilen von Abfragen.

Es ist typisch, Betriebs- / Transaktionsdatenspeicher vom Berichtswesen zu trennen. Letztere müssen möglicherweise aus rechtlichen Gründen Daten aufbewahren (z. B. sieben Jahre Finanzdaten für die Finanzprüfung), und Sie möchten nicht, dass all dies in Ihrem Transaktionsdatenspeicher gespeichert wird.

So partitionieren Sie Ihre Transaktionsdaten nach einem bestimmten Zeitmaß (wöchentlich, monatlich, vierteljährlich, jährlich) und verschieben ältere Partitionen über ETL in Ihren Berichterstellungs- / Verlaufsdatenspeicher. Es kann ein Data Warehouse mit einem Sternschema und Dimensionen sein oder nicht. Sie würden Data Warehousing-Berichtstools verwenden, um Ad-hoc-Abfragen und Roll-ups durchzuführen und Batch-Jobs auszuführen, um regelmäßige Berichte zu erstellen.

Es wird nicht empfohlen, Berichte für Ihren Transaktionsdatenspeicher zu erstellen.

Wenn Sie lieber weitermachen möchten, sind hier weitere Gedanken:

1. "Best" ist subjektiv und was funktioniert.
2. Ich würde ein Berichtsprodukt kaufen, anstatt es selbst zu schreiben.
3. Wenn Sie eine relationale Datenbank verwenden, ist SQL das einzige Spiel in der Stadt.
4. Gespeicherte Prozeduren hängen davon ab, ob Sie die Fähigkeiten haben, sie zu schreiben.

Projektmanagement-Software, die Sie im Haus einsetzen? Ich würde kaufen, bevor ich bauen würde. So etwas wie Rallye und Microsoft Project.

Zunächst einige Begriffe, die Sie als Task-Seite Transactional und als Reporting-Seite Analytics bezeichnen.

Sie haben bereits CQRS erwähnt, was ein großartiger Ansatz ist, aber es gibt wenig dokumentierte praktische Anwendung des Ansatzes.

Was intensiv getestet wurde, ist die Ergänzung Ihrer Transaktionsverarbeitung durch eine analytische Verarbeitungsengine. Dies wird manchmal als Data Warehousing oder Data Cubes bezeichnet. Das größte Problem bei der Analyse ist, dass der Versuch, Abfragen für Ihre Transaktionsdaten in Echtzeit auszuführen, bestenfalls ineffizient ist, da eine Datenbank nur zum Lesen oder Schreiben optimiert werden kann. Für Transaktionen möchten Sie hohe Schreibgeschwindigkeiten, um Verzögerungen bei der Verarbeitung / Ausführung zu vermeiden. Für die Berichterstellung möchten Sie hohe Lesegeschwindigkeiten, damit Entscheidungen getroffen werden können.

Wie können diese Probleme berücksichtigt werden? Der einfachste zu verstehende Ansatz besteht darin, ein reduziertes Schema für Ihre Berichterstellung und ETL (Extract Transform Load) zu verwenden, um Daten vom normalisierten Transaktionsschema zum denormalisierten Analyseschema zu übertragen. Die ETL wird regelmäßig über einen Agenten ausgeführt und lädt die Analysetabelle vor, damit sie schnell von Ihrer Reporting-Engine gelesen werden kann.

Ein großartiges Buch, um sich über Data Warehousing zu informieren, ist das Data Warehouse Toolkit von Ralph Kimball. Für eine praxisnahe Herangehensweise. Laden Sie die Testversion von SQL Server herunter, und greifen Sie auf das Microsoft Data Warehouse-Toolkit zu, das die allgemeine Diskussion des ersten Buches aufnimmt, aber zeigt, wie die Konzepte unter Verwendung von SQL Server angewendet werden.

Es gibt mehrere verknüpfte Bücher auf diesen Seiten, die weitere Informationen zu ETL, Star Schema Design, BI, Dashboards und anderen Themen enthalten.

Der schnellste Weg, um von Ihrem Standort zum gewünschten Standort zu gelangen, besteht darin, einen BI-Experten zu beauftragen und ihn zu begleiten, während er das umsetzt, was Sie benötigen.

Was ist mit der Berichtsseite? Sind Data Warehouses akzeptabel oder haben sie ein schlechtes Design, weil sie Geschäftslogik in die Datenbank und in die Daten selbst integrieren?

Ich glaube nicht, dass Sie über Geschäftslogik sprechen, das ist mehr Berichtslogik. Was machen Benutzer mit den Informationen auf diesem Bildschirm? Ist es nur für Statusaktualisierungen gedacht? Ihr Domain-Modell wird zum Modellieren von Transaktionsvorgängen verwendet. Die Berichterstellung ist ein anderes Problem. Das Abrufen der Daten von SQL Server oder das Speichern in einem Data Warehouse ist für Berichterstellungsszenarios ausreichend.

Ihr Domain-Modell sollte die Invarianten Ihrer Domain erzwingen, z. B. dass ein Projektmitglied nicht zur gleichen Zeit bei demselben Projekt buchen kann oder nur x Stunden pro Woche buchen kann. Sie können dieses Projekt auch nicht buchen, da es vollständig ist usw. usw. Der Status Ihres Domain-Modells (die Daten) kann für die Berichterstellung separat kopiert werden.

Um die Abfrageleistung zu verbessern, können Sie eine materialisierte Ansicht verwenden. Wenn eine Operation für Ihr Modell festgeschrieben wird (z. B. Buchen Sie 4 Stunden dieser Person, um x zu projizieren) und sie erfolgreich ist, kann sie ein Ereignis auslösen, das Sie dann in einer Berichtsdatenbank speichern und die erforderlichen Berechnungen für Ihren Bericht durchführen können. Es wird dann sehr schnell sein, danach abzufragen.

Halten Sie Ihren Transaktions- und Berichtskontext getrennt. Eine relationale Datenbank wurde erstellt, um zu melden, dass ein Domänenmodell nicht vorhanden war.

BEARBEITEN

Nützlicher Blogbeitrag zum Thema http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

Es ist 4 Jahre später und ich habe diese Frage gerade wiedergefunden und ich habe die Antwort für mich.

Abhängig von Ihrer Anwendung und ihren spezifischen Anforderungen können Ihre Domain- / Transaktionsdatenbank und Ihre Berichterstellung separate "Systeme" oder "Engines" sein oder sie können von einem System bedient werden. Sie sollten jedoch logisch getrennt sein - was bedeutet, dass sie unterschiedliche Methoden zum Abrufen und Bereitstellen von Daten für die Benutzeroberfläche verwenden.

Ich bevorzuge es, dass sie physisch getrennt sind (zusätzlich zur logischen Trennung), aber oft fängt man sie zusammen an (physisch) und trennt sie dann, wenn die Anwendung reift.

Wie auch immer, sie sollten logisch unterschiedlich sein. Es ist in Ordnung, die Geschäftslogik im Berichtssystem zu duplizieren. Wichtig ist, dass das Berichtssystem die gleiche Antwort erhält wie das Domänensystem - es wird jedoch wahrscheinlich auf unterschiedliche Weise dorthin gelangen. Auf Ihrem Domänensystem sind beispielsweise (wahrscheinlich) eine Menge sehr strenger Geschäftsregeln im prozeduralen Code implementiert. Das Berichtssystem könnte dieselben Regeln implementieren, wenn es die Daten liest, dies jedoch über SET-basierten Code (z. B. SQL) tun würde.

So könnte eine Weiterentwicklung der Architektur Ihrer Anwendung im Verlauf der Entwicklung realistisch aussehen:

Ebene 1 - Logisch getrennte Domänen- und Berichtssysteme, die sich jedoch immer noch in derselben Codebasis und Datenbank befinden

Stufe 2 - Logisch getrennte Domänen- und Berichtssysteme, jetzt jedoch getrennte Datenbanken mit Synchronisierung.

Stufe 3 - Logisch und physisch getrennte Domänen- und Berichtssysteme sowie getrennte Datenbanken mit Synchronisierung.

Die Hauptidee ist, dass Reporting und Domain völlig unterschiedliche Bedürfnisse haben. Unterschiedliche Datenprofile (Lese- und Schreibintervalle sowie Aktualisierungsintervalle), unterschiedliche Leistungsanforderungen usw. Daher müssen sie unterschiedlich implementiert werden, und dies erfordert eine gewisse Doppelung der Geschäftslogik.

Es liegt an Ihrem Unternehmen, einen Weg zu finden, um die Geschäftslogik der Domäne und der Berichtssysteme auf dem neuesten Stand zu halten.

Bericht / Dashboard wird benötigt, um eine Liste der aktiven Projekte anzuzeigen

Zustand jedes Projekte sollten als statisch gespeichert werden, pro-berechnet und gut formatierte Informationen in der Datenbank und alle Simulationen sollten auf dem Client als WebApp behandelt werden.

Budget Erschöpfungstermin bei aktueller Brennrate

Diese Art der Projektion sollte nicht bei Bedarf ausgeführt werden. Das Verwalten dieser Informationen auf Anfrage, wie das Durchführen von Berechnungen zu Ressourcen, Kursen, Aufgaben, Meilensteinen usw., führt zu einer umfangreichen Verwendung der Berechnungsebene, ohne dass diese Ergebnisse für zukünftige Aufrufe erneut verwendet werden.

Wenn Sie sich eine verteilte Umgebung ( private oder öffentliche Cloud ) vorstellen , werden Sie die enormen Kosten für die Berechnungsebene, den geringen Datenbankverbrauch und den vollständigen Cache-Mangel zu spüren bekommen.

Sollte dies zuerst über die Domain ausgeführt werden? Was ist mit der Leistung?

Das Design Ihrer Software sollte die Möglichkeit beinhalten, die zur Erzielung des erforderlichen Ergebnisses erforderlichen Berechnungen während der "Dateneingabe" und nicht während des Lesens zu normalisieren. Dieser Ansatz reduziert den Einsatz von Rechenressourcen erheblich und erstellt vor allem Tabellen, die vom Kunden als "schreibgeschützt" betrachtet werden können. Dies ist der erste Schritt, um einen soliden und einfachen Caching-Mechanismus zu erstellen.

Bei einer Suche zuerst, bevor die Softwarearchitektur vervollständigt wird, könnte es sich um ein verteiltes Cachesystem handeln .

(Anfrage: Aggregation)! = 1: 1

Meine Überlegung ist daher (sowohl für das erste als auch für das zweite Beispiel), zu verstehen, wann es richtig ist, die Daten zu normalisieren, mit dem Ziel, die Aggregationen pro Clientanforderung zu reduzieren. Was nicht 1: 1 sein kann (Anfrage: Aggregation), wenn ein Ziel ein nachhaltiges System ist.

Verteilen Sie die Berechnung auf dem Client

Eine andere Frage, bevor das Design der Software abgeschlossen ist, könnte sein, wie viel Normalisierung wir dem Client-Browser delegieren wollen?

Es hieß MV *, es ist wahr, dass es heutzutage in Mode ist. Darüber hinaus besteht einer seiner Zwecke darin, eine WebApp (Single Page App) zu erstellen, die als Gegenwart vieler komplexer Anwendungen angesehen werden kann (und zum Glück für Rechnungen, die dies bedeuten) Wir zahlen an den Cloud-Provider (diese werden im Client ausgeführt).

Meine Schlussfolgerung lautet daher:

1. Verstehen, wie viele Operationen wirklich notwendig sind, um die Präsentation der Daten durchzuführen;

2. Analysieren Sie, wie viele davon im Hintergrund ausgeführt werden können (und nach ihrer Normalisierung über ein Cache-System verteilt werden können).

3. Verstehen, wie viele Vorgänge auf dem Client ausgeführt werden können, Abrufen der Konfiguration der Projekte, Ausführen in Ansichten auf der Webanwendung und Reduzieren der im Back-End durchgeführten Berechnung;

Verwenden Sie den Cache für die Abfrage, verwenden Sie die Domäne für die Zwischenspeicherung.

Beim Stackoverflow gibt es eine Funktion namens "Top-User". Möglicherweise finden Sie auf der Seite der Top-Benutzer eine Zeile mit der Aufschrift "In diesen Summen sind nur Fragen und Antworten enthalten, die nicht von Community-Wiki stammen ( täglich aktualisiert )". Dies zeigt an, dass die Daten zwischengespeichert sind.

Aber wieso?

Für Leistungsprobleme vielleicht. Vielleicht haben sie das gleiche Problem mit dem Verlust von Domain-Logik (in diesem Fall sind nur Fragen und Antworten, die nicht von Community-Wikis stammen, in diesen Summen enthalten).

Wie?

Ich weiß nicht wirklich, wie sie das gemacht haben, also hier nur eine Vermutung :)

Zuerst müssen wir die Zielfrage / -antworten finden. Eine Planungsaufgabe könnte funktionieren, indem Sie einfach alle potenziellen Ziele abrufen.

Lassen Sie uns zweitens nur eine Frage / Antwort betrachten. Ist es ein Nicht-Community-Wiki? Ist es innerhalb von 30 Tagen? Mit Domain-Modellen ist die Beantwortung recht einfach. Zählen Sie die Stimmen und speichern Sie sie, wenn Sie zufrieden sind.

Jetzt haben wir den Cache, sie sind die Ausgabe von Domain-Ableitungen. Die Abfrage ist schnell und einfach, da nur einfache Kriterien angewendet werden müssen.

Was ist, wenn die Ergebnisse "Echtzeit" sein müssen?

Ereignisse können die Hilfe tun. Anstatt das Zwischenspeichern mit einer Planungsaufgabe auszulösen, können wir den Prozess in viele Unterprozesse aufteilen. Wenn zum Beispiel jemand über die Antwort von Hippoom abstimmt, veröffentlichen wir ein Ereignis, das die Aktualisierung des Cache der Top-Benutzer von Hippoom auslöst. In diesem Fall sehen wir häufig schnelle kleine Aufgaben.

Ist CQRS notwendig?

Weder beim Scheduling Task Approach noch beim Events Approach. Aber cqrs hat einen Vorteil. Der Cache ist in der Regel stark anzeigeorientiert. Wenn einige Elemente zunächst nicht benötigt werden, werden sie möglicherweise nicht berechnet und gecacht. CQRS mit Event-Sourcing hilft dabei, den Cache für Verlaufsdaten wiederherzustellen, indem Ereignisse wiederholt werden.

Einige verwandte Fragen:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -reiche-Domain-mit-massiven-Operationen / 19416703 # 19416703

Ich hoffe es hilft :)

Haftungsausschluss:
Ich bin ziemlich unerfahren in Anwendungen mit Domain-Modellen.
Ich verstehe alle Konzepte, und ich habe bereits lange darüber nachgedacht, wie ich diese Konzepte auf die Anwendungen anwenden kann, an denen ich arbeite (die reich an Domänen sind, denen jedoch OO, tatsächliche Domänenmodelle usw. fehlen) .
Diese Frage ist eines der Hauptprobleme, mit denen ich ebenfalls konfrontiert war. Ich habe eine Idee, wie ich das lösen kann, aber wie ich gerade sagte ... es ist nur eine Idee, die ich mir ausgedacht habe.
Ich habe es noch nicht in ein aktuelles Projekt implementiert, sehe aber keinen Grund, warum es nicht funktionieren sollte.

Nachdem ich das klargestellt habe, habe ich mir Folgendes ausgedacht:

Wenn jemand ein Projekt bearbeitet, laden und speichern Sie es trotzdem über Ihr Domain-Modell.
In diesem Moment, Sie haben die alle Informationen geladen alle Ihre Kennzahlen zu berechnen (Gesamtbudget, bis dato etc.) für dieses Projekt.

Sie können dies im Domänenmodell berechnen und zusammen mit dem restlichen Domänenmodell in der Datenbank speichern.
So ist die ProjectKlasse in Ihrem Domain - Modell wird einige Eigenschaften wie hat TotalBudget, EffortToDateusw., und es wird auch Spalten mit diesen Namen in den Datenbanktabellen, in denen Sie Ihr Domain - Modell gespeichert wird (in den gleichen Tabellen oder in einer separaten Tabelle ... Doesn ist egal) .

Natürlich müssen Sie einen einmaligen Durchlauf durchführen, um den Wert für alle vorhandenen Projekte zu berechnen, während Sie damit beginnen. Danach werden die Daten jedoch jedes Mal, wenn ein Projekt über das Domänenmodell bearbeitet wird, automatisch mit den aktuell berechneten Werten aktualisiert.

Wenn Sie also einen Bericht benötigen, sind alle erforderlichen Daten bereits vorhanden (vorberechnet), und Sie können einfach Folgendes tun:

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

Es spielt keine Rolle, ob Sie die Daten direkt aus den Tabellen abrufen, in denen das Domänenmodell gespeichert ist, oder ob Sie die Daten auf irgendeine Weise in eine zweite Datenbank, in ein Data Warehouse oder was auch immer extrahieren:

1. Wenn sich Ihr Berichterstellungsspeicher von Ihrem tatsächlichen Datenspeicher unterscheidet, können Sie die Daten einfach aus den "Domänenmodelltabellen" kopieren.
2. Wenn Sie Ihren tatsächlichen Datenspeicher direkt abfragen, sind die Daten bereits vorhanden und Sie müssen nichts berechnen

In beiden Fällen befindet sich die Geschäftslogik für die Berechnungen genau an einer Stelle: dem Domänenmodell.
Sie brauchen es nirgendwo anders, daher ist es nicht notwendig, es zu duplizieren.