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

44

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?

Richard
quelle
3
Entschuldigung, das wollte ich nicht. Der Mod sagte mir, ich solle hier einen neuen Beitrag schreiben, konnte aber anscheinend die gleiche Frage migrieren, sodass ich zwei bekam. Das tut mir leid.
Richard
Ich bin verwirrt. Hat das noch niemand gemacht? Niemand steht vor diesem Problem?
Richard
Ist Ihre Aufgabentrennung / Berichterstattung nicht ein bisschen theoretisch? Sie können sagen, dass die Berichtsseite auch Geschäftsregeln hat, sodass Sie nicht vermeiden können, Geschäftslogik in die gesamte Kette aufzunehmen. Unabhängig davon, welches BI-Tool Sie verwenden, müssen Sie von den Eingabeaufgaben bis zur Berichterstellung Zwischenergebnisse erstellen (Definition von aggregierten Objekten usw.). Dann kommt es auf die Frage an, wo was zu knirschen ist. Vielleicht können Sie sich dem Problem mit einer Piramide (mit abgeschnittener Spitze) oder einer Trichtermetapher nähern.
Jan Doggen
@ JanDoggen Das ist genau mein Punkt. Das BI-Tool muss über BL-Logik verfügen. Jetzt dupliziere ich die BL, die sich in der umfangreichen Domäne meines Softwareprodukts befindet. Ist das in Ordnung?
Richard

Antworten:

16

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!

RibaldEddie
quelle
Hi @RibaldEddie. Danke für die Antwort. Kommt mir nicht schlecht vor. Sie sagen also, es ist in Ordnung, die gespeicherten Prozeduren als Domänenebene für den berichtenden begrenzten Kontext zu behandeln?
Richard
Wenn Sie gute Gründe haben, dies in Ihrer Situation zu tun, dann ist das in Ordnung. Persönlich bin ich mir nicht sicher, ob ich SP auf jeden Fall verwenden würde, außer vielleicht für eine Datenvalidierung oder -bereinigung, sonst würde ich mich in jedem Fall davor scheuen.
RibaldEddie
4

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.

theinsaneone
quelle
3

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.

Adrian Schneider
quelle
3

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.

MyXEDNotes
quelle
Ich bin mir nicht sicher, wie das mit meiner Frage zusammenhängt oder wie es so schnell 3 Stimmen bekommen hat. Wollten Sie auch hier einen Link einfügen?
Richard
2
Es sieht so aus, als ob das Kopfgeld für diese Antwort automatisch vergeben wurde. Diese Antwort scheint mir Kauderwelsch zu sein, und ich hätte dem NICHT das Kopfgeld zugesprochen.
Richard
2

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.

Duffymo
quelle
Vielen Dank @duffymo. Diese Daten werden nicht nur aus rechtlichen Gründen gespeichert. Es sind Tonnen von Daten, die regelmäßig verwendet und gemeldet werden. Das Unternehmen lebt und stirbt von den Berichten und Dashboards. Immerhin ist es Projektmanagement-Software. Wie können diese Berichte und Dashboards am besten mit den Daten versorgt werden? Mit SQL aggregieren und rausholen? Ist es in Ordnung, wenn die Geschäftslogik in den Store Procedures enthalten ist? Alle meine Fragen sind noch unbeantwortet!
Richard
Sie haben eine Antwort - Data Warehouse. Klingt so, als wollten Sie das nicht hören. Siehe oben für Änderungen.
Duffymo
Ist es dann in Ordnung, dass die Geschäftslogik in der Domäne im DTS- und Data Warehouse dupliziert wird? Wenn ich diese Daten dann herausnehme, verwende ich überhaupt ein Domain-Modell? Oder ziehen Sie einfach die Daten mit gespeicherten Prozeduren heraus und zeigen Sie sie in der Ansicht an? Um Ihre obigen Punkte anzusprechen: Ich kann kein Berichtsprodukt kaufen. Der Grund, warum ich dies schreibe, ist, dass das Unternehmen bestimmte Anforderungen hat, die von keinem Berichtsprodukt erfüllt werden. Ich benutze eine relationale Datenbank und habe sehr gute SQL-Kenntnisse. Aber ich möchte nicht auf das zurückgreifen, was ich gut kann, sondern auf das, was gutes Design ist.
Richard
Re: buy before you build - Sie können ein Unternehmen nicht dazu zwingen, sein Geschäft an die Software anzupassen, wenn es Software für sein Geschäft entwickeln möchte. Rallye und MS Project passen nicht zu allen Projektmanagementanforderungen. Überhaupt.
Richard
Kann natürlich nicht erzwingen. Aber jedes Unternehmen kann entscheiden, was in seinem eigenen Interesse liegt. Wenn Sie keine Projektmanagement-Software verkaufen, liegt es in Ihrem Interesse, zu prüfen, ob es besser ist, sie zu kaufen. Genau wie Buchhaltungssoftware. Wer würde bei klarem Verstand ein Hauptbuch von Grund auf neu schreiben?
Duffymo
2

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.

Michael Brown
quelle
Hallo Mike. Ich bin mit Datawarehousing und BI seit 15 Jahren bestens vertraut. Meine Frage beschäftigt sich mit dem Umgang damit in einem domänengetriebenen Designkontext. Sind Datawarehouses in Ordnung? Oder sind sie eine Verfälschung Ihrer Domain-Business-Schicht? Wenn die Antwort darin besteht, ein Data Warehouse aufzubauen und die Daten von dort abzurufen, gibt es dafür eine Menge Literatur und Ratschläge. Dann duplizieren Sie jedoch die Geschäftslogik außerhalb Ihrer Domäne. Ist das in Ordnung? Das ist meine frage
Richard
Wie ich bereits erwähnt habe, müssen CQRS-Adressen gut sein, indem das Repository in eine Command- (Transaktions-) und eine Query-Seite (Berichterstellung) unterteilt wird. Aber auch ohne die anderen Funktionen von CQRS sind Data Warehouse und etl Clients Ihrer Domain, ändern diese jedoch nicht. Die BL ist also immer noch in der Domain enthalten.
Michael Brown
1
Sie ändern die Domäne nicht. Müssen dann alle ETL-Prozesse und Datentransformationen zum Erstellen der Daten für das Data Warehouse Ihre Domäne durchlaufen? Andernfalls wird Ihr BL in der gesamten Logik Ihrer ETL-Prozesse dupliziert.
Richard
1
Ja, ich würde sagen, dass eine ETL die Domain direkt IDEAL verwenden sollte. Auf diese Weise können Sie spröde Tools vermeiden, die bei jeder internen Änderung an der Datenbank neu geschrieben werden müssen.
Michael Brown
2

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

Scott Millett
quelle
2

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 1 - Logisch getrennte Domänen- und Berichtssysteme, jedoch immer noch in derselben Codebasis

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

Stufe 2 - Logisch getrennte Domänen- und Berichtssysteme, jetzt getrennte Datenbanken

Stufe 3 - Logisch und physisch getrennte Domänen- und Berichtssysteme sowie 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.

Richard
quelle
1

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;

marcocs
quelle
Hallo Marcocs, danke für deine Antwort. Zwei Probleme, die ich bei der Durchführung von Voraggregationen auf der Clientseite sehe, sind: 1. Sie haben viele Aktionen, die zu einer Vorberechnung führen können, und 2. Möglicherweise sind viele Vorberechnungen erforderlich. Füge die beiden zusammen und du bekommst einen sehr hohen Ressourcenverbrauch. Zum Beispiel ... muss das Budget neu berechnet werden, wenn A. sich ein Rechnungssatz auf dem Budget ändert (dies kann durch eine Reihe von Faktoren ausgelöst werden ... eine Benutzeraktion oder einen geplanten Rollover auf einen neuen Satz, zum Beispiel den Wechselkurse ändern sich zu Beginn eines neuen Geschäftsjahres), oder B. Die Zusammensetzung des Budgets ...
Richard
... ändert sich zum Beispiel Stunden hinzugefügt oder abgezogen. Die Liste geht weiter. Was # 2 der Aggregationen anbelangt, muss der Kunde morgen die Aggregationen nach Regionen anzeigen, dann nach Mitarbeitern, Städten, Branchen oder anderen verrückten Attributen für das Projekt oder die zugehörige Entität. Werden Sie all dies vorab aggregieren? Wenn ja, erstellen Sie jetzt eine OLAP-Engine. Sind diese Aggregationen auch im Projektobjekt in der Domäne gespeichert? Wenn Sie die Daten präsentieren, wann werden Sie einen berechneten Wert gegenüber dem vorberechneten Wert verwenden. Haben Sie diese Arbeit in einer realen Welt App gemacht?
Richard
Ich interessiere mich für diesen Ansatz, aber er stellt mich vor viele Probleme.
Richard
Ich habe ein System zur Verteilung von Einnahmen in Betrieb. Mein Problem bestand darin, den aktuellen Status der Einnahmen auf der Grundlage der Daten anzuzeigen, die von den Subnetzwerken der Agenten generiert wurden (einschließlich Auszahlungen, Einzahlungen, Jackpot usw.). Die Teilnetze nutzen ihr Guthaben ständig, dies erhöht / verringert den Gewinn des Netzwerkvaters. Die Aufteilung der Einnahmen erfolgt periodisch jeden Montag, Problem bestand darin, in Echtzeit die Entwicklung des Gewinns zu zeigen und die virtuellen zu aktualisieren Budget aller Netzwerke.
Marcocs
Um Aggregationen über die Netzwerke zu vermeiden und alle Werte bei jeder Anforderung in Echtzeit zu verteilen, wird ein temporärer Bereitstellungsprozess kontinuierlich ausgeführt, um die Einnahmen der Netzwerke zu normalisieren. Bei jeder Anforderung werden die berechneten Werte durch Aggregation der Werte summiert Werte, die nicht in der temporären Bereitstellung enthalten sind (ich arbeite nur mit dem letzten Update-Element). Die Tabelle der Transaktionen (die offensichtlich diejenige ist, die die Last in dieser Anwendung erleidet) wurde mit Tabellenpartitionen behandelt .
Marcocs
1

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 :)

Yugang Zhou
quelle
0

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.

Christian Specht
quelle
Hallo Christian, ich bin froh zu sehen, dass ich nicht der einzige bin, der damit zu kämpfen hat. Danke für deine Antwort. Siehe meine Kommentare zu Marcocs Antwort für die Probleme, die ich mit diesem Ansatz sehe. Irgendwelche Ideen zum Umgang mit denen wäre dankbar!
Richard