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


44

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?



3
Przepraszam, nie chciałem. Mod kazał mi tutaj repostować, ale najwyraźniej był w stanie przenieść to samo pytanie, więc dostałem dwa. Przepraszam za to.
richard

Jestem zmieszany. Czy nikt tego nie zrobił? Nikt nie ma tego problemu?
richard

Czy twoje „rozdzielenie problemów” nie jest zadaniem teoretycznym? Można powiedzieć, że strona raportująca ma również reguły biznesowe, więc nie można uniknąć logiki biznesowej w całym łańcuchu. Bez względu na to, jakiego narzędzia BI użyjesz, będziesz musiał tworzyć wyniki pośrednie od zadań wejściowych do etapu raportowania (definiowanie obiektów agregujących itd.). Potem sprowadza się do pytania, gdzie chrupnąć co. Być może możesz podejść do problemu z piramidą (z odciętą górą) lub metaforą lejka.
Jan Doggen

@JanDoggen Właśnie o to mi chodzi. Narzędzie BI MUSI mieć logikę BL. Teraz powielam BL, który znajduje się w bogatej domenie mojego oprogramowania. Czy to w porządku?
richard

Odpowiedzi:


16

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!


Cześć @RibaldEddie. Dziękuję za odpowiedź. Nie wydaje mi się gibki. Mówisz więc, że można traktować procedury składowane jako warstwę domenową dla kontekstu związanego z raportowaniem?
richard

Jeśli masz dobry powód, aby to zrobić w swojej sytuacji, to w porządku. Osobiście nie jestem pewien, czy użyłbym SP w każdym przypadku, z wyjątkiem może dla pewnej weryfikacji danych lub czyszczenia, w przeciwnym razie w każdym przypadku bym się tego unikał.
RibaldEddie

4

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.


3

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.


3

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ń.


Nie jestem pewien, w jaki sposób odnosi się to do mojego pytania lub w jaki sposób uzyskało 3 głosy tak szybko. Czy chciałeś również zamieścić tutaj link?
richard

2
Wygląda na to, że nagroda została przyznana automatycznie na tę odpowiedź. Ta odpowiedź wydaje mi się bełkotem i NIE przyznałbym jej nagrody.
richard

2

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.


Dzięki @duffymo. Te dane nie są przechowywane tylko ze względów prawnych. To mnóstwo danych, które są regularnie wykorzystywane i zgłaszane. Firma żyje i umiera dzięki raportom i pulpitom nawigacyjnym. W końcu to oprogramowanie do zarządzania projektami. Jaki jest najlepszy sposób dostarczenia tych raportów i pulpitów nawigacyjnych z danymi? Agregowanie i wyciąganie go za pomocą SQL? Czy logika biznesowa może znajdować się w procedurach sklepu? Wszystkie moje pytania wciąż pozostają bez odpowiedzi!
richard

Masz odpowiedź - hurtownia danych. Wygląda na to, że nie to chciałeś usłyszeć. Patrz wyżej dla edycji.
duffymo

Czy zatem logika biznesowa w domenie może być zduplikowana w hurtowni danych i danych? Ponadto, po wyciągnięciu tych danych, czy w ogóle używam jakiegokolwiek modelu domeny? Lub po prostu wyciągnij dane z procedur przechowywanych i wyświetl w widoku? Aby zająć się powyższymi punktami: Nie mogę kupić produktu do raportowania ... powodem, dla którego piszę, jest to, że firma ma określone potrzeby, które nie zostały zaspokojone przez żaden produkt do raportowania. Korzystam z relacyjnej bazy danych i mam bardzo dobre umiejętności SQL. Ale nie chcę wybierać domyślnie tego, w czym jestem dobry, chcę robić to, co jest dobre.
richard

Re: kup zanim zbudujesz - nie możesz zmusić firmy do dopasowania swojej działalności do oprogramowania, gdy chce, aby oprogramowanie było dostosowane do jej działalności. Rally i MS Project nie odpowiadają wszystkim potrzebom zarządzania projektami. W ogóle.
richard

Oczywiście nie mogę wymusić. Ale każda firma decyduje, co leży w ich interesie. Jeśli nie zajmujesz się sprzedażą oprogramowania do zarządzania projektami, w twoim interesie leży ocena, czy lepiej go kupić. Podobnie jak oprogramowanie księgowe. Kto przy zdrowych zmysłach napisałby od podstaw księgę główną?
duffymo

2

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.


Cześć Mike. Jestem bardzo zaznajomiony z magazynowaniem danych i BI, ponieważ robię to od 15 lat. Moje pytanie dotyczy tego, jak sobie z tym poradzić w kontekście projektowania opartego na domenie. Czy magazyny danych są w porządku? A może są one fałszowaniem warstwy biznesowej Twojej domeny? Jeśli odpowiedzią jest zbudowanie hurtowni danych i stamtąd dane, istnieje wiele literatury i porad na ten temat. Ale następnie powielasz logikę biznesową poza swoją domeną. Czy to w porządku? To moje pytanie.
richard

Tak jak wspomniałem, adresy CQRS, które są potrzebne, dzieląc repozytorium na stronę Command (transakcyjną) i Query (raportowanie). Ale nawet bez innych pułapek CQRS hurtownia danych i etl są klientami twojej domeny, ale ich nie modyfikują. BL jest więc nadal zawarty w domenie.
Michael Brown

1
Nie modyfikują domeny ... więc wszystkie procesy ETL i transformacje danych w celu utworzenia danych dla hurtowni danych muszą przejść przez domenę? W przeciwnym razie BL zostanie zduplikowany w całej logice procesów ETL.
Richard

1
Tak, powiedziałbym, że ETL powinien IDEALNIE używać domeny bezpośrednio. Pozwoliłoby to uniknąć kruchych narzędzi, które trzeba przepisywać przy każdej wewnętrznej zmianie bazy danych.
Michael Brown

2

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


2

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 1 - Logicznie wydzielona domena i systemy raportowania, ale wciąż w tej samej bazie kodu

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

Poziom 2 - Logicznie oddzielone systemy domen i raportowania, ale teraz osobne bazy danych

Poziom 3 - Domeny i systemy raportowania oddzielone logicznie i fizycznie oraz 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.


1

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;


Cześć Marcocs, dziękuję za odpowiedź. Dwa problemy, które widzę podczas robienia wstępnych agregacji po stronie klienta, to: 1. masz DUŻO działań, które mogą doprowadzić do wstępnego obliczenia i 2. Może być DUŻO potrzebnych wstępnych obliczeń. Złóż je razem, a otrzymasz naprawdę duże zużycie zasobów. Na przykład ... budżet będzie musiał zostać ponownie obliczony, gdy A. zmieni się jakakolwiek stawka rozliczeniowa w budżecie (może to zostać wywołane przez szereg rzeczy ... działanie użytkownika lub zaplanowane przejście na nową stawkę, na przykład stawki zmieniają się na początku nowego roku obrotowego), lub B. Skład budżetu ...
richard

... zmiany na przykład godziny dodane lub odjęte. Itd. Lista jest długa. Jeśli chodzi o # 2, potrzebne są agregacje ... jutro klient musi zobaczyć agregacje według regionu, następnie chce zobaczyć pracownika, miasto, branżę lub inny zwariowany atrybut projektu lub powiązanego podmiotu. Czy zsumujesz je wszystkie? Jeśli tak, to teraz tworzysz silnik OLAP ... Czy te agregacje należą również do projektu Obiekt w domenie? Kiedy przedstawisz dane, kiedy użyjesz wartości obliczonej w stosunku do wartości wstępnie obliczonej. Itd. Czy wykonałeś tę pracę w aplikacji z prawdziwego świata?
Richard

Interesuje mnie to podejście, ale stanowi dla mnie wiele problemów.
richard

Mam uruchomiony system dystrybucji zarobków, moim problemem było pokazanie obecnego stanu zarobków na podstawie danych generowanych przez podsieci agentów (w tym wypłat, depozytów, jackpota, ...). Podsieci stale wykorzystują swoją równowagę , co zwiększa / dekretuje zyski ojca sieci. Dystrybucja zysków odbywa się okresowo w każdy poniedziałek, problemem było pokazanie w czasie rzeczywistym ewolucji zysku i aktualizacja wirtualnego budżet wszystkich sieci.
marcocs

Aby uniknąć agregacji w sieci i dystrybuować wszystkie wartości w czasie rzeczywistym za każdym razem, gdy wysyłane jest żądanie, proces wdrażania tymczasowego jest wykonywany w sposób ciągły w celu normalizacji zarobków w sieci. Za każdym razem, gdy przesyłasz żądanie, obliczone wartości są sumowane przez agregację wartości, które nie są uwzględnione w tymczasowym wdrożeniu (pracuję tylko z elementem ostatniej aktualizacji). Tabela transakcji (która oczywiście jest obciążona w tej aplikacji) została obsadzona partycjami tabeli .
marcocs

1

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


0

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ć.


Cześć Christian, cieszę się, że nie jestem jedynym, który się z tym boryka. Dzięki za odpowiedź. Zobacz moje komentarze do odpowiedzi Marcocsa na problemy, które widzę przy takim podejściu. Wszelkie pomysły dotyczące radzenia sobie z nimi będą mile widziane!
richard
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.