Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Analizy Biznesowe i Systemowe Przedsiębiorstw - Projektowanie Systemów Informatycznych
Na temat projektowania, modelowania, analizy itp. napisano wiele. Wiele razy też czytałem i obserwowałem jak psuje się projekty tak zwaną optymalizacją, która jest jednak nie raz niczym innym jak upraszaniem prowadzącym często do katastrofy podczas przyszłej rozbudowy.
Często spotykam się z tezami, że modele tworzone w stylu DDD ([[Domain Driven Design]], ang. Projektowanie Zorientowane na Dziedzinę systemu) są mało optymalne. Najczęściej przytaczanym przykładem jest krytyka agregatów ([[wzorzec projektowy Agregat]], obiekt biznesowy modelowany jako obiekt główny i jego komponenty) jako mało wydajnych konstrukcji w przypadku zapytań o filtrowane i agregowane raporty. Jest to prawda ale wzorzec agregatu służy do zarządzania tymi obiektami a nie do tworzenia zaawansowanych wyliczeń z użyciem ich wybranych atrybutów. Zgodnie z DDD raczej należy wtedy zaprojektować osobną klasę (agregat) będącą utworzonym „na boku” stosem danych do analiz. Czy tak się robi? Oczywiście, w dużych systemach stawia się dodatkową hurtownie danych, których architektura jest przystosowana do takich własnie zapytań, w mniejszych projektuje się specjalna tablicę danych do takich raportów.
Niestety spotykam się często z upraszczaniem dobrych modeli „bo będzie się lepiej raportowało”. Czy lepiej to się okaże w praktyce zaś model „zepsuty” (najczęściej optymalizacja polega na upraszczaniu konstrukcji agregatu) staje się później nie raz niemożliwy do rozbudowy.
Właśnie mam w ręku książkę [[Joshua Blocha Java Efektywne Programowanie]] (kupiłem by poczytać co robią programiści a nie programować ;)))) i tam jest rozdział o optymalizacji, a w nim super sentencja: staraj się pisać programy poprawne a nie szybkie, po szczegóły tej myśli odsyłam do książki… Jakakolwiek optymalizacja na etapie projektowania jest przedwczesna, dopiero po skompilowaniu i testach należy ocenić czy program jest za wolny, bo może nie jest …
Czemu lubię i polecam styl DDD? Bo nawet jak nie znamy przyszłych zmian (nowych wymagań) to na pewno projekt będzie się dało rozbudować zamiast zmieniać. Dlaczego? Bo jeśli projekt dobrze „modeluje” rzeczywistość to znaczy, że jeśli tylko coś zmieni się w tej rzeczywistości będzie możliwe to, do takiego samego odwzorowania w projekcie. (tu polecam także artykuł ze stron devlab.pl o tak zwanych ValueObject): Ważne jest także przestrzeganie hermetyzacji, która także modeluje rzeczywistość. Innymi słowy „jest tylko jeden sposób by poznać lub zmienić zawartość mojej teczki: poprosić mnie”. Optymalizacja polegająca na udostępnianiu danych obiektów wprost, jeśli nie (o zgrozo) bezpośrednio z innych obiektów, to z pomocą operacji get/set (bezpośrednie pytania o konkretne atrybuty i operacje na nich) mamy na tacy to co powinno być chronione. Skutki są takie, że być może nieco uprościliśmy kod ale jego przyszła rozbudowa i konserwacja raczej będzie koszmarem. Zapewne wielu z Was spotkało się z przypadkiem, poprawienia (uzupełnienia) jakiejś funkcjonalności powodującą lawinę błędów w innych. To jeden z typowych efektów łamania zasady hermetyzacji.
Polecam artykuł z MSDN (cytat poniżej), dodam że DDD to raczej styl analizy i projektowania a nie metodyka bo nie istnieje recepta na analizę i modelowanie. Trzeba zrozumieć to co się modeluje i odwzorować w postaci modelu w implementowanym oprogramowaniu. Porównanie z jaskinią Platona jest doskonałe :):
Możecie przyrównać [[teorie o Jaskini Platona]] do formuły modelowania DDD. Wiele z tych zaleceń pomaga nam zbliżyć się idealnego modelu w ogóle. Droga prowadząca do tworzonego kodu zależy od głów wielu ekspertów dziedzinowych i projektantów, sponsorów projektu, wymagań branży w której pracujemy. Dlatego ma ogromny sens patrzenie (razem) na projektowany system (oprogramowanie) jak na cienie odwzorowujące rzeczywistość na ścianie jaskini przed jej mieszkańcami. (źr. An Introduction To Domain-Driven Design.)
Na koniec mała uwaga dla zwolenników metod zorientowanych na przypadki użycia. Projektowanie na bazie [[sesji JAD]] i kolekcjonowaniu przypadków użycia bardzo często prowadzi do bardzo kosztownych analiz i opasłych dokumentów, gdzie odkrywane potem w prototypach nowe wymagania niszczą budżet i harmonogram projektu, jeśli nie wyraża się na nie zgody niszczą przydatność produktu. Piękną metaforę przytoczył [[Martin Fowler]]:
Wyobraźmy sobie kogoś, kto chce napisać program symulujący partnera do gry w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi cechy tej gry scenariuszem: „Gracz uderza białą kulę, która przemieszcza się z konkretną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewną odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować (scenariusz) parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie.” (źr. [[Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997]], wtrącenia moje).
Powyższy cytat, moim zdaniem powinien sobie wziąć do serca każdy dobry analityk i projektant. Powiem też, że dla mnie sam ten cytat wart był ceny książki. To jest właśnie sposób myślenia, który gorąco polecam i sam stosuję. Z innej książki: przedmiotem analizy jest to co ogólne, rzemiosło w szczegółach jako narzędzie projektowania się nie sprawdza.
Na koniec polecam także inny ciekawy artykuł kończący się słowami:
… gdy sytuacja robi się złożona, dobrze jest zdecydować się na podejście w stylu DDD, ponieważ jest dużo bardziej czytelniejsze i lepiej odpowiada skali skomplikowanych i dużych aplikacji. (źr. La Gal?re / Propaganda Kapitana Pazura ? Blog Archive ? O walidacji słów kilka).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Masz pytania to treści artykułu?
Kliknij tu!
Wiele w tym prawdy. Warto jednakże zauważyć, że wskazując problemy z optymalizacją tak na prawdę mówisz o jej karykaturze. Optymalizacja winna prowadzić do subiektywnie(z punktu widzenia projektu) lepszego(szybszego, łatwiejszego dla użytkownika) osiągnięcia tych samych celów, przy zachowaniu wymagań (w tym ograniczeń i łatwości modyfikacji). Dobra optymalizacja na etapie projektowania pozwala zachować zalety DDD, czy inne parametry przyjęte w wymaganiach. Rozwiązań jest wiele – ot choćby odpowiednie agregaty dla filtrów, lub agregacje o poziom niżej w taksonomii. Ale to już zbyt szczegółowe kwestie:)
Jeśli chodzi o DDD i problem raportowania czy prezentowania danych spomiędzy agregatów oraz optymalizację wydajności, to warto spojrzeć dodatkowo na wzorzec CQRS (Command-Query Responsibility Segregation). W skrócie chodzi o to, że rozdzielamy w systemie odpowiedzialność za przetwarzanie komend zmieniających stan systemu od części wyciągającej dane do prezentacji. Efekt jest taki, że model dziedziny (w oparciu o DDD) odwzorowany jest w części przetwarzającej komendy, zaś struktura danych w części Query jest maksymalnie uproszczona i odpowiada stricte potrzebom widoków prezentowanych użytkownikowi.
Nie do końca. Po pierwsze, to źródło danych nie musi agregować danych z różnych systemów, więc nie jest potrzebny złożony ETL. Po drugie, zwykle te dane nie są wykorzystywane do przygotowywania skomplikowanych raportów historycznych z możliwością analizy wielowymiarowej, a raczej jako część zwykłego systemu transakcyjnego więc zamiast systemu OLAP wystarczy baza danych (relacyjna lub nie).
pisząc „hurtonia danych” miałem raczej na myśli dedykowaną do raportowania strukturę a nie od razu ETL i wielowymiarowe modele danych, rzecz w tym, by „prowadzić” równolegle płaską tabelę do raportowania. Jednak zapewne potrzebne będzie oszacowanie na ile ważna jest funkcja operacyjna agregatów a na ile raportowa…
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
Wiele w tym prawdy. Warto jednakże zauważyć, że wskazując problemy z optymalizacją tak na prawdę mówisz o jej karykaturze. Optymalizacja winna prowadzić do subiektywnie(z punktu widzenia projektu) lepszego(szybszego, łatwiejszego dla użytkownika) osiągnięcia tych samych celów, przy zachowaniu wymagań (w tym ograniczeń i łatwości modyfikacji).
Dobra optymalizacja na etapie projektowania pozwala zachować zalety DDD, czy inne parametry przyjęte w wymaganiach. Rozwiązań jest wiele – ot choćby odpowiednie agregaty dla filtrów, lub agregacje o poziom niżej w taksonomii. Ale to już zbyt szczegółowe kwestie:)
Wzmianka o jaskini Platona to strzał w dziesiątkę. Chyba muszę zacząć pisać artykuły, bo ja wpadłem na to już parę lat temu 🙂
Jeśli chodzi o DDD i problem raportowania czy prezentowania danych spomiędzy agregatów oraz optymalizację wydajności, to warto spojrzeć dodatkowo na wzorzec CQRS (Command-Query Responsibility Segregation). W skrócie chodzi o to, że rozdzielamy w systemie odpowiedzialność za przetwarzanie komend zmieniających stan systemu od części wyciągającej dane do prezentacji. Efekt jest taki, że model dziedziny (w oparciu o DDD) odwzorowany jest w części przetwarzającej komendy, zaś struktura danych w części Query jest maksymalnie uproszczona i odpowiada stricte potrzebom widoków prezentowanych użytkownikowi.
Czy to przypadkiem nie skutkuje „produktem”: Model Dziedziny operacyjny plus „hurtownia danych na boku” do raportowania?
Nie do końca. Po pierwsze, to źródło danych nie musi agregować danych z różnych systemów, więc nie jest potrzebny złożony ETL. Po drugie, zwykle te dane nie są wykorzystywane do przygotowywania skomplikowanych raportów historycznych z możliwością analizy wielowymiarowej, a raczej jako część zwykłego systemu transakcyjnego więc zamiast systemu OLAP wystarczy baza danych (relacyjna lub nie).
pisząc „hurtonia danych” miałem raczej na myśli dedykowaną do raportowania strukturę a nie od razu ETL i wielowymiarowe modele danych, rzecz w tym, by „prowadzić” równolegle płaską tabelę do raportowania. Jednak zapewne potrzebne będzie oszacowanie na ile ważna jest funkcja operacyjna agregatów a na ile raportowa…
Ok. W takim razie mówimy o tym samym 🙂 Rzeczywiście skutkiem jest zazwyczaj osobna baza danych pod zapytania.