Wzorce najlepszych praktyk lub wzorców projektowych w zakresie pobierania danych do raportów i pulpitów nawigacyjnych w aplikacji bogatej w domeny

Po pierwsze, chcę powiedzieć, że wydaje się to zaniedbanym pytaniem / obszarem, więc jeśli to pytanie wymaga poprawy, pomóż mi uczynić z tego świetne pytanie, które może przynieść korzyści innym! Szukam porady i pomocy od osób, które wdrożyły rozwiązania rozwiązujące ten problem, a nie tylko pomysłów do wypróbowania.

Z mojego doświadczenia wynika, że ​​istnieją dwie strony aplikacji - strona „zadaniowa”, która w dużej mierze opiera się na domenie i gdzie użytkownicy intensywnie współdziałają z modelem domeny („silnikiem” aplikacji) i stroną raportującą, gdzie użytkownicy uzyskać dane na podstawie tego, co dzieje się po stronie zadania.

Po stronie zadania jasne jest, że aplikacja z bogatym modelem domeny powinna mieć logikę biznesową w modelu domeny, a baza danych powinna być używana głównie do utrwalania. Rozdzielając obawy, każda książka jest o tym napisana, wiemy, co robić, super.

Co ze stroną zgłaszającą? Czy hurtownie danych są akceptowalne, czy też mają zły projekt, ponieważ zawierają logikę biznesową w bazie danych i samych danych? Aby agregować dane z bazy danych do danych hurtowni danych, musisz zastosować logikę biznesową i reguły do ​​danych, a ta logika i reguły nie pochodziły z twojego modelu domeny, ale z procesów agregacji danych. Czy to źle?

Pracuję nad dużymi aplikacjami do zarządzania finansami i projektami, w których logika biznesowa jest rozległa. Podczas raportowania tych danych często będę musiał wykonać DUŻO agregacji, aby pobrać informacje wymagane dla raportu / pulpitu nawigacyjnego, a agregacje zawierają wiele logiki biznesowej. Ze względu na wydajność robiłem to z wysoce zagregowanymi tabelami i procedurami składowanymi.

Jako przykład załóżmy, że potrzebny jest raport / pulpit nawigacyjny, aby wyświetlić listę aktywnych projektów (wyobraź sobie 10 000 projektów). Każdy projekt będzie wymagał pokazania zestawu wskaźników, na przykład:

1. cały budżet
2. wysiłek do tej pory
3. szybkość spalania
4. data wyczerpania budżetu przy bieżącym tempie spalania
5. itp.

Każda z nich wiąże się z dużą logiką biznesową. Nie mówię tylko o pomnożeniu liczb lub o prostej logice. Mówię o tym, aby uzyskać budżet, musisz zastosować arkusz stawek z 500 różnymi stawkami, po jednym na czas każdego pracownika (w niektórych projektach inne mają mnożnik), stosując wydatki i wszelkie odpowiednie znaczniki itp. logika jest rozległa. Uzyskanie tych danych w rozsądnym czasie dla klienta wymagało dużo agregacji i dostrajania zapytań.

Czy należy to najpierw przeprowadzić przez domenę? Co z wydajnością? Nawet w przypadku prostych zapytań SQL ledwo dostaję te dane wystarczająco szybko, aby klient mógł je wyświetlić w rozsądnym czasie. Nie wyobrażam sobie, aby próbować dostarczyć te dane do klienta wystarczająco szybko, jeśli nawadniam wszystkie te obiekty domeny oraz mieszam, dopasowuję i agreguję ich dane w warstwie aplikacji lub próbuję agregować dane w aplikacji.

Wydaje się, że w tych przypadkach SQL jest dobry w przetwarzaniu danych i dlaczego go nie użyć? Ale wtedy masz logikę biznesową poza modelem domeny. Wszelkie zmiany w logice biznesowej będą musiały zostać zmienione w modelu domeny i schematach agregacji raportów.

Naprawdę nie wiem, jak zaprojektować część raportowania / pulpit nawigacyjny dowolnej aplikacji w odniesieniu do projektowania opartego na domenie i dobrych praktyk.

Dodałem tag MVC, ponieważ MVC jest stylem projektowania i używam go w moim obecnym projekcie, ale nie mogę zrozumieć, w jaki sposób dane raportowania pasują do tego typu aplikacji.

Szukam jakiejkolwiek pomocy w tej dziedzinie - książek, wzorów, słów kluczowych w Google, artykułów, czegokolwiek. Nie mogę znaleźć żadnych informacji na ten temat.

EDYCJA I INNY PRZYKŁAD

Kolejny idealny przykład, z którym się dzisiaj spotkałem. Klient chce raportu dla zespołu sprzedaży klienta. Chcą czegoś, co wydaje się prostą miarą:

Jaka jest do tej pory roczna sprzedaż dla każdego sprzedawcy?

Ale to skomplikowane. Każdy sprzedawca uczestniczył w wielu okazjach sprzedażowych. Niektórzy wygrali, inni nie. W każdej okazji sprzedaży jest wielu sprzedawców, którym przydzielono procent kredytu na sprzedaż według ich roli i udziału. Wyobraźmy sobie teraz, że przechodzimy przez domenę w celu ... nawodnienia obiektu, które musielibyście zrobić, aby pobrać te dane z bazy danych dla każdego sprzedawcy:

Zbierz wszystkie SalesPeople->
Dla każdego otrzymaj ich SalesOpportunities->
Dla każdego uzyskaj procent sprzedaży i oblicz ich kwotę sprzedaży,
a następnie dodaj wszystkie SalesOpportunitykwoty sprzedaży.

I to JEDNA metryka. Możesz też napisać zapytanie SQL, które może to zrobić szybko i sprawnie i dostroić je tak, aby było szybkie.

EDYCJA 2 - Wzór CQRS

Czytałem o Wzorcu CQRS i chociaż intrygujący, nawet Martin Fowler twierdzi, że nie został przetestowany. Jak więc ten problem został rozwiązany w przeszłości? W pewnym momencie musieli się z tym zmierzyć wszyscy. Jakie jest ugruntowane lub dobrze stosowane podejście z udokumentowanymi sukcesami?

Edycja 3 - Systemy raportowania / narzędzia

Inną rzeczą do rozważenia w tym kontekście są narzędzia do raportowania. Usługi Reporting Services / Crystal Reports, Analysis Services i Cognoscenti itp. Oczekują danych z SQL / bazy danych. Wątpię, aby Twoje dane później trafiły do ​​Twojej firmy. A jednak oni i inni tacy jak oni są istotną częścią raportowania w wielu dużych systemach. W jaki sposób dane są odpowiednio przetwarzane, gdy istnieje źródło logiki biznesowej w źródle danych dla tych systemów, a także ewentualnie w samych raportach?

To bardzo krótka odpowiedź, ale od razu do sedna sprawy:

Jeśli chodzi o DDD, może myślisz o raportowaniu jako o ograniczonym kontekście ?, więc zamiast myśleć o modelu domeny „THE”, powinieneś pomyśleć, że możesz mieć więcej niż jeden model. Tak więc jest w porządku, jeśli domena raportowania ma logikę biznesową raportowania, podobnie jak w domenie transakcyjnej może być logika biznesowa transakcyjna.

Jeśli chodzi o, powiedzmy, procedury składowane SQL a model domeny w kodzie aplikacji, w systemie raportowania obowiązują te same zalety i wady, co w przypadku systemu transakcyjnego.

Ponieważ widzę, że dodałeś nagrodę do pytania, przeczytałem pytanie ponownie i zauważyłem, że prosisz o określone zasoby na ten temat, więc pomyślałem, że zacznę od zasugerowania, abyś spojrzał na inne pytania dotyczące przepełnienia stosu w tej sprawie, i znalazłem ten https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

Ogólnym celem tego jest użycie CQRS jako wzorca dla twojego systemu, który jest zgodny z DDD, i poleganie na zadaniach po stronie zapytania jako sposobie wykonania raportowania, ale nie jestem pewien, czy jest to pomocna odpowiedź w Twój przypadek.

Znalazłem również ten http://www.martinfowler.com/bliki/ReportingDatabase.html , który znalazłem link tutaj: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

Oto ciekawy artykuł od ACM na ten temat: http://dl.acm.org/citation.cfm?id=2064685, ale jest za zaporą, więc nie mogę go przeczytać (nie jest członkiem ACM :().

Tutaj znajduje się również odpowiedź na podobne pytanie: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

i ten: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

Mam nadzieję że to pomoże!

Rozumiem z twojego pytania, że: Aplikacja do codziennych zadań ma

Zobacz >> Kontroler >> Model (BL) >> Baza danych (dane)

Aplikacja do celów sprawozdawczych

Zobacz >> Kontroler >> Model >> Baza danych (dane + BL)

Tak więc zmiana BL dla „ aplikacji zadań ” doprowadzi również do zmiany w „ raportowaniu ” BL. To jest twój prawdziwy problem, prawda? Cóż, w porządku, aby zrobić zmiany dwukrotnie, ten ból i tak musisz wziąć. Powodem jest to, że oba BL są rozdzielone według ich obaw. Jeden służy do pobierania danych, a drugi do gromadzenia danych. Również twoja oryginalna BL i agregująca BL będą napisane w innej technologii lub języku ( C # / java i SQL proc ). Nie ma przed tym ucieczki.

Weźmy inny przykład, niezwiązany konkretnie z raportowaniem. Załóżmy, że firma XXX śledzi maile wszystkich użytkowników w celu interpretacji i sprzedaje te informacje firmom marketingowym. Teraz będzie miał jeden BL do interpretacji i jeden BL do agregacji danych dla firm marketingowych. Obawy są różne dla obu BL. Jutro, jeśli ich BL zmieni się tak, że maile pochodzące z Kuby powinny zostać zignorowane, logika biznesowa zostanie zmieniona po obu stronach.

Raportowanie jest ograniczonym kontekstem lub subdomeną, mówiąc swobodnie. Rozwiązuje potrzebę biznesową gromadzenia / agregowania danych i przetwarzania ich w celu uzyskania wywiadu gospodarczego.

Sposób implementacji tej subdomeny prawdopodobnie zapewni równowagę między (najbardziej) poprawnym architektonicznie sposobem, w jaki można to zrobić, a tym, na co pozwoli twoja infrastruktura. Lubię zaczynać od pierwszej strony i podążać w kierunku drugiej tylko w razie potrzeby.

Prawdopodobnie możesz podzielić to na dwa podstawowe problemy, które rozwiązujesz:

1. Agregowanie lub magazynowanie danych. Powinno to przetworzyć niektóre źródło danych i połączyć informacje w taki sposób, aby były przechowywane w innym źródle danych.

2. Zapytanie o zagregowane źródło danych w celu zapewnienia analizy biznesowej.

Żaden z tych problemów nie odwołuje się do żadnej konkretnej bazy danych ani silnika pamięci. Warstwa domeny powinna po prostu zajmować się interfejsami zaimplementowanymi w warstwie infrastruktury przez różne adaptery pamięci.

Możesz mieć różnych pracowników lub zaplanowane wykonywanie pracy, które jest podzielone na kilka ruchomych części:

• Coś do zapytania
• Coś do zagregowania
• Coś do przechowywania

Mam nadzieję, że zobaczysz, że niektóre CQRS świecą.

Po stronie raportowania wystarczy wykonać zapytania, ale nigdy bezpośrednio do bazy danych. Przejdź tutaj przez interfejsy i warstwę domeny. To nie jest ta sama domena problemów, co twoje podstawowe zadania, ale nadal powinna istnieć pewna logika, której chcesz się trzymać.

Gdy tylko zanurzysz się bezpośrednio w bazie danych, bardziej na niej polegasz, co może ostatecznie zakłócać potrzeby w zakresie danych twojej oryginalnej aplikacji.

Ponadto, przynajmniej dla mnie, zdecydowanie wolę pisać testy i rozwijać się w kodzie niż zapytania lub procedury składowane. Lubię też nie angażować się w określone narzędzia, dopóki nie będzie to absolutnie konieczne.

Odzyskiwanie dużych ilości informacji w sieciach rozległych, w tym w Internecie, jest problematyczne ze względu na problemy wynikające z opóźnienia odpowiedzi, braku bezpośredniego dostępu pamięci do zasobów obsługujących dane oraz odporności na awarie.

To pytanie opisuje wzorzec projektowy do rozwiązywania problemów związanych z obsługą wyników zapytań zwracających duże ilości danych. Zazwyczaj zapytania te byłyby zadawane przez proces klienta w sieci rozległej (lub Internet), z jedną lub kilkoma warstwami pośrednimi, do relacyjnej bazy danych znajdującej się na zdalnym serwerze.

Rozwiązanie obejmuje wdrożenie kombinacji strategii wyszukiwania danych, w tym zastosowanie iteratorów do przeglądania zestawów danych i zapewnienie klientowi odpowiedniego poziomu abstrakcji, podwójnego buforowania podzbiorów danych, wyszukiwania danych wielowątkowych i dzielenia zapytań.

Typowe jest oddzielanie operacyjnych / transakcyjnych magazynów danych od raportowania. Ten ostatni może mieć wymagania dotyczące przechowywania danych z przyczyn prawnych (np. Siedem lat danych finansowych na potrzeby audytu finansowego), a nie chcesz tego wszystkiego w swoim magazynie danych transakcyjnych.

Więc podzielisz dane transakcyjne na określony czas (tygodniowo, miesięcznie, kwartalnie, rocznie) i przeniesiesz starsze partycje do magazynu danych raportowania / historii za pośrednictwem ETL. Może to być hurtownia danych ze schematem i wymiarami gwiazdy. Korzystasz z narzędzi raportowania hurtowni danych, aby wykonywać zapytania doraźne oraz zestawienia i zadania wsadowe w celu generowania raportów okresowych.

Nie polecam raportowania w stosunku do Twojego sklepu danych transakcyjnych.

Jeśli wolisz kontynuować, oto więcej myśli:

1. „Najlepsze” jest subiektywne i działa.
2. Kupiłbym produkt do raportowania, a nie sam.
3. Jeśli używasz relacyjnej bazy danych, SQL jest jedyną grą w mieście.
4. Procedury przechowywane zależą od tego, czy umiesz je pisać.

Oprogramowanie do zarządzania projektami, którego używasz w domu? Kupiłbym, zanim zbudowałem. Coś jak Rally i Microsoft Project.

Najpierw trochę terminologii, którą nazywasz stroną zadaniową, jest znany jako transakcyjny, a stroną raportującą jest Analytics.

Wspomniałeś już o CQRS, które jest świetnym podejściem, ale mało jest udokumentowanego praktycznego zastosowania tego podejścia.

To, co zostało dokładnie przetestowane, to uzupełnienie przetwarzania transakcyjnego o silnik przetwarzania analitycznego. Jest to czasami określane jako hurtownia danych lub kostki danych. Największym problemem związanym z analizą jest to, że próba uruchamiania zapytań dotyczących danych transakcyjnych w czasie rzeczywistym jest co najmniej nieefektywna, ponieważ tak naprawdę można zoptymalizować bazę danych do odczytu lub zapisu. W przypadku transakcji potrzebujesz wysokich prędkości zapisu, aby uniknąć opóźnień w przetwarzaniu / wykonywaniu zadań. Do raportowania potrzebujesz wysokich prędkości odczytu, aby móc podejmować decyzje.

Jak uwzględnić te problemy? Najprostszym podejściem do zrozumienia jest użycie spłaszczonego schematu do raportowania i ETL (ekstrakcja obciążenia transformacji) w celu przesłania danych ze znormalizowanego schematu transakcyjnego do zdenormalizowanego schematu analitycznego. ETL jest uruchamiany regularnie przez agenta i wstępnie ładuje tabelę analityczną, aby była gotowa do szybkiego odczytu z silnika raportowania.

Świetną książką na przyspieszenie hurtowni danych jest Data Warehouse Toolkit autorstwa Ralpha Kimball'a. Aby uzyskać więcej praktycznego podejścia. Pobierz wersję próbną programu SQL Server i wybierz zestaw narzędzi Microsoft Data Warehouse, który zawiera ogólne omówienie pierwszej książki, ale pokazuje, jak zastosować koncepcje za pomocą programu SQL Server.

Istnieje kilka połączonych książek z tych stron, które zawierają więcej szczegółów na temat ETL, Star Schema Design, BI, pulpitów nawigacyjnych i innych tematów, które pomogą ci iść dalej.

Najszybszym sposobem na dotarcie z miejsca, w którym jesteś, do miejsca, w którym chcesz się znaleźć, jest zatrudnienie Eksperta BI i śledzenie go, podczas gdy on wdraża to, czego potrzebujesz.

Co ze stroną zgłaszającą? Czy hurtownie danych są akceptowalne, czy też mają zły projekt, ponieważ zawierają logikę biznesową w bazie danych i samych danych?

Nie sądzę, że mówisz o logice biznesowej, to bardziej logika raportowania. Co użytkownicy robią z informacjami na tym ekranie, czy są to tylko aktualizacje statusu? Twój model domeny służy do modelowania operacji transakcyjnych, raportowanie to inna sprawa. Pobieranie danych z SQL Server lub umieszczanie ich w hurtowni danych jest odpowiednie do tworzenia scenariuszy raportowania.

Twój model domeny powinien egzekwować niezmienniki twojej domeny, takie jak członek projektu nie może zarezerwować tego samego projektu w tym samym czasie lub może zarezerwować tylko x liczby godzin tygodniowo. Lub nie możesz zarezerwować tego projektu, ponieważ jest on ukończony itp. Itd. Stan modelu domeny (dane) można skopiować osobno, aby raportować.

Aby poprawić wydajność zapytań, możesz użyć zmaterializowanego widoku. Gdy operacja zostanie popełniona przeciwko Twojemu modelowi (np. Zarezerwuj 4 godziny czasu tej osoby na projekt x) i zakończy się ona powodzeniem, może wygenerować zdarzenie, które możesz następnie zapisać w bazie danych raportów i wykonać niezbędne obliczenia dla raportu. Wówczas zapytanie o nią będzie bardzo szybkie.

Zachowaj odrębność kontekstu transakcji i raportowania, zbudowano relacyjną bazę danych na potrzeby raportowania modelu domeny.

EDYTOWAĆ

Przydatny post na blogu na ten temat http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

Minęły 4 lata i znów znalazłem to pytanie i mam na to odpowiedź.

W zależności od aplikacji i konkretnych potrzeb baza danych domeny / transakcji i raportowanie mogą być oddzielnymi „systemami” lub „silnikami”, lub mogą być obsługiwane przez jeden system. Powinny one jednak być logicznie oddzielne - co oznacza, że ​​używają różnych sposobów wyszukiwania i dostarczania danych do interfejsu użytkownika.

Wolę, aby były fizycznie oddzielne (oprócz logicznego oddzielenia), ale wiele razy zaczynasz je razem (fizycznie), a następnie, gdy aplikacja dojrzewa, oddzielasz je.

Tak czy inaczej, znowu powinny być logicznie różne. Można powielać logikę biznesową w systemie raportowania. Ważne jest to, że system raportowania otrzymuje tę samą odpowiedź, co system domen - ale są szanse, że dostanie się tam za pomocą różnych środków. Na przykład w Twoim systemie domen będzie mnóstwo bardzo ścisłych reguł biznesowych zaimplementowanych w kodzie proceduralnym (prawdopodobnie). System raportowania mógłby wdrożyć te same reguły, gdy odczytuje dane, ale robiłby to za pomocą kodu opartego na SET (np. SQL).

Oto, jak ewolucja architektury aplikacji może realistycznie wyglądać w miarę ewolucji:

Poziom 1 - Logicznie oddzielone domeny i systemy raportowania, ale wciąż w tej samej bazie kodu i bazie danych

Poziom 2 - Logicznie oddzielone systemy domen i raportowania, ale teraz oddzielne bazy danych z synchronizacją.

Poziom 3 - Domeny i systemy raportowania oddzielone logicznie i fizycznie oraz oddzielne bazy danych z synchronizacją.

Główną ideą jest to, że raportowanie i domena mają radykalnie różne potrzeby. Różne profile danych (odczyty vs. częstotliwość zapisów i aktualizacji), różne wymagania dotyczące wydajności itp. Dlatego muszą być różnie wdrażane, co wymaga pewnego powielenia logiki biznesowej.

Od Twojej firmy zależy opracowanie logiki biznesowej domeny i systemów raportowania.

raport / pulpit jest potrzebny, aby wyświetlić listę aktywnych projektów

Stan każdego projektu powinien być przechowywany jako statyczna, obliczona i dobrze sformatowana informacja w bazie danych, a wszelkie symulacje powinny być obsługiwane na kliencie jako WebApp.

data wyczerpania budżetu przy bieżącym tempie spalania

tego typu projekcji nie należy uruchamiać na żądanie. Zarządzanie tymi informacjami na żądanie, takie jak wykonywanie obliczeń dotyczących zasobów, stawki, zadań, kamieni milowych itp., Spowoduje szerokie wykorzystanie warstwy obliczeniowej bez ponownego wykorzystywania tych wyników do przyszłych połączeń.

Wyobrażając sobie środowisko rozproszone ( chmurę prywatną lub publiczną ), otrzymasz ogromne koszty w warstwie obliczeniowej, niskie wykorzystanie bazy danych i całkowity brak pamięci podręcznej.

Czy należy to najpierw przeprowadzić przez domenę? Co z wydajnością?

Projekt twojego oprogramowania powinien obejmować zdolność do normalizacji obliczeń niezbędnych do uzyskania wymaganego wyniku podczas „wprowadzania danych”, a nie podczas odczytu. Takie podejście znacznie zmniejsza zużycie zasobów obliczeniowych, a przede wszystkim tworzy tabele, które klient może uznać za „tylko do odczytu”. To pierwszy krok do stworzenia solidnego i prostego mechanizmu buforowania.

Najpierw szukaj, zanim ukończysz architekturę oprogramowania, może to być rozproszony system pamięci podręcznej .

(żądanie: agregacja)! = 1: 1

Dlatego rozważam (dla pierwszego i drugiego przykładu), spróbuj zrozumieć, kiedy należy znormalizować dane, mając na celu zmniejszenie agregacji na żądania klientów. Który nie może być 1: 1 (żądanie: agregacja), jeśli jednym celem jest uzyskanie zrównoważonego systemu.

Rozłóż obliczenia na kliencie

Kolejne pytanie, przed zakończeniem projektowania oprogramowania, może być, ile normalizacji chcemy delegować przeglądarkę klienta?

Został nazwany MV *, prawdą jest, że jest dziś modny, oprócz tego jednym z jego celów jest stworzenie WebApp (aplikacja jednostronicowa), którą można uznać za obecną w wielu złożonych aplikacjach (i na szczęście dla rachunków, które płacimy dostawcy usług w chmurze, są one wykonywane w kliencie).

Mój wniosek jest zatem następujący:

1. Zrozumienie, ile operacji jest naprawdę niezbędnych do przeprowadzenia prezentacji danych;

2. Przeanalizuj, ile z nich można wykonać w tle (a następnie rozprowadzić przez system pamięci podręcznej, po ich normalizacji);

3. Zrozumienie, ile operacji można wykonać w kliencie, uzyskanie konfiguracji projektów, uruchomienie jej w Widoku w aplikacji sieci Web, a tym samym zmniejszenie obliczeń wykonywanych w back-endie;

Użyj pamięci podręcznej do zapytania, użyj domeny do buforowania.

Istnieje funkcja zwana „najlepszymi użytkownikami” w przepływie stosów. Możesz znaleźć wiersz na stronie czołowych użytkowników, który mówi: „Tylko te pytania i odpowiedzi spoza społeczności są uwzględnione w tych podsumowaniach ( aktualizowane codziennie )”. Oznacza to, że dane są buforowane.

Ale dlaczego?

Może z powodu problemów z wydajnością. Być może mają takie same obawy związane z nieszczelnością logiki domeny (w tym przypadku w tych podsumowaniach uwzględniono tylko pytania i odpowiedzi spoza społeczności).

W jaki sposób?

Naprawdę nie wiem, jak to zrobili, więc zgaduję :)

Najpierw musimy znaleźć docelowe pytanie / odpowiedź. Zadanie planowania może działać, wystarczy pobrać wszystkie potencjalne cele.

Po drugie, spójrzmy tylko na jedno pytanie / odpowiedź. Czy jest to wiki spoza społeczności? Czy to w ciągu 30 dni? Odpowiedź na modele domen jest dość łatwa. Policz głosy i buforuj je, jeśli są zadowolone.

Teraz mamy pamięć podręczną, są one wynikiem pochodnych domen. Zapytanie jest szybkie i łatwe, ponieważ można zastosować tylko proste kryteria.

Co jeśli wyniki muszą być bardziej „w czasie rzeczywistym”?

Wydarzenia mogą pomóc. Zamiast wyzwalać buforowanie przy użyciu zadania planowania, możemy podzielić proces na wiele podprocesów. Na przykład, gdy ktoś głosuje na odpowiedź hippooma, publikujemy zdarzenie uruchamiające aktualizację pamięci podręcznej najlepszych użytkowników hippooma. W takim przypadku możemy zobaczyć często szybkie, małe zadania.

Czy CQRS jest konieczne?

Ani w podejściu do planowania zadań, ani w podejściu do zdarzeń. Ale cqrs ma przewagę. Pamięć podręczna jest zwykle bardzo zorientowana na wyświetlanie, jeśli niektóre elementy na początku nie są wymagane, możemy ich nie obliczyć i nie buforować. CQRS z pozyskiwaniem zdarzeń pomaga zrekonstruować pamięć podręczną dla danych historycznych, odtwarzając zdarzenia.

Niektóre powiązane pytania:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -rich-domain-with-Massive-Operations / 19416703 # 19416703

Mam nadzieję, że to pomoże :)

Oświadczenie:
Jestem dość niedoświadczony w aplikacjach z modelami domen.
Rozumiem wszystkie koncepcje i już od dawna zastanawiam się, jak zastosować te koncepcje do aplikacji, nad którymi pracuję (które są bogate w domeny, ale brakuje OO, rzeczywistych modeli domen itp . ) .
To pytanie jest jednym z kluczowych problemów, z którymi również się spotkałem. Mam pomysł, jak to rozwiązać, ale jak już powiedziałem ... wpadłem na pomysł.
Nie wdrożyłem go jeszcze w rzeczywistym projekcie, ale nie widzę powodu, dla którego miałby nie działać.

Teraz, gdy to wyjaśniłem, oto co wymyśliłem - wykorzystam twój pierwszy przykład (metryki projektu), aby wyjaśnić:

Kiedy ktoś edytuje projekt, ładujesz go i zapisujesz za pomocą modelu domeny.
W tej chwili, to mają wszystkie informacje załadowany obliczyć wszystkie swoje dane (całkowity budżet, wysiłku do daty etc.) dla tego projektu.

Możesz to obliczyć w modelu domeny i zapisać w bazie danych wraz z resztą modelu domeny.
Więc Projectklasa w modelu domeny będzie mieć pewne właściwości, takie jak TotalBudget, EffortToDateitd., I tam też będzie z tymi nazwami kolumn w tabelach bazy danych, gdzie model domeny są przechowywane (w tych samych stołach, lub w osobnym stole ... robi nie ma znaczenia) .

Oczywiście musisz wykonać jednorazowy bieg, aby obliczyć wartość dla wszystkich istniejących projektów, zaczynając od tego. Ale potem dane są automatycznie aktualizowane o bieżące obliczone wartości za każdym razem, gdy projekt jest edytowany za pomocą modelu domeny.

Kiedy więc potrzebujesz dowolnego raportu, wszystkie wymagane dane już tam są (wstępnie obliczone) i możesz po prostu zrobić coś takiego:

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

Nie ma znaczenia, czy pobierasz dane bezpośrednio z tabel, w których przechowywany jest model domeny, czy też w jakiś sposób wyodrębniasz dane do drugiej bazy danych, hurtowni danych lub cokolwiek innego:

1. Jeśli Twój sklep z raportami różni się od rzeczywistego magazynu danych, możesz po prostu skopiować dane z „tabel modelu domeny”
2. Jeśli bezpośrednio zapytasz o rzeczywistą składnicę danych, dane już tam są i nie musisz niczego obliczać

W obu przypadkach logika biznesowa dla obliczeń znajduje się dokładnie w jednym miejscu: modelu domeny.
Nigdzie indziej nie jest potrzebny, więc nie trzeba go duplikować.