Diagram prawdę Ci powie
Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod…
CQRS czyli jak osiągnąć wydajność c.d.
Rok temu pisałem o wzorcu CQRS, tamten wpis bazował głównie na artykule M.Fowlera i stanowił raczej zajawkę tematu. Teraz mam troszkę własnych doświadczeń, także w dyskusjach z programistami, i przytoczę…
Dane są nieważne bo liczy się przede wszystkim mechanizm działania
Często słyszę, że to trudne i pracochłonne (dodatkowe klasy w modelu) ale niestety zbyt prosty projekt potrafi być kosztowniejszy w rozbudowie w porównaniu z pierwotnym wytworzeniem, dlatego jak klient w ramach wymagań wpisuje (a wpisuje coraz częściej): system ma umożliwiać łatwe rozszerzenia funkcjonalności, to należy go tak projektować, w przeciwnym wypadku wymaganie to nie jest spełnione... Druga uwaga: często sami klienci zabijają swoje projekty żądając na samym początku dokumentowania wszystkich szczegółów jakie im do głowy przyjdą nie potrafiąc jednocześnie opisać mechanizmu działania ich organizacji. To niestety często spotykane zjawisko, z którym moim zdaniem należy walczyć. Paradoksalnie złożoność systemów biznesowych tkwi w mechanizmie ich funkcjonownia a nie w danych które zbierają (których nie raz jest po prostu za dużo...)
Analiza procesowa a obiektowa czyli niedopasowanie oporu
Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
Dlaczego nie podoba mi się klasa Pracownik?
Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem): ... byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model). Gdzie problem? [...] No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system "ma w środku" Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.