Często spotykam się z zarzutem, że udziwniam modele, także te analityczne. Chodzi o stosowanie,  między innymi, wzorca analitycznego o wdzięcznej nazwie Fabryka ([[wzorzec projektowy fabryka abstrakcyjna]] lub, zależnie od sytuacji, [[wzorzec projektowy Prototyp]]).

[[Analiza dziedziny systemu]] polega między innymi na “zrozumieniu istoty rzeczy”.  Pierwszą rzeczą jaką da się dostrzec w “świecie” jest to, że każdy byt ma swojego (s)twórcę. W naszym otoczeniu nic się samo nie robi, więc rozsądek nakazywał by uznawanie tego faktu także w projektach programistycznych.Oczywiście, jeżeli uznajemy ten styl projektowania, obowiązku nie ma. Kod programu to abstrakcja, jej autorem jest twórca programu, więc po co, ja analityk i projektant, o tym piszę?

Powód jest prosty: każdy (no prawie) zamawiający oczekuje, że “program będzie pozwalał na łatwe wprowadzanie zmian i aktualizację w takt zachodzących zmian w otoczeniu biznesowym”. Co to oznacza?

To znaczy, że

im bardziej oprogramowanie – abstrakcja świata, którego opis ono modeluje i przetwarza – będzie odbiegało od realiów tego świata, tym trudniej będzie utrzymać zgodność tego oprogramowania ze zmianami zachodzącymi wokół nas.

Pewnie wielu czytelników, zadając dostawcy oprogramowania pytanie o koszt wprowadzenia nowych funkcjonaliści lub modyfikacji istniejących,  spotkało się z odpowiedzią: “to będzie dużo kosztowało” (czasem więcej niż koszt wytworzenia systemu).  To z reguły właśnie efekt tego, że model użyty do wytworzenia oprogramowania odbiega od rzeczywistości, został uproszczony lub wręcz inaczej zrealizowany. Typowym przykładem takiego stanu rzeczy jest opieranie architektury oprogramowania na fundamencie w postaci relacyjnego, znormalizowanego model danych. Niestety “świat” nie jest “znormalizowany”, nafaszerowany jest powtórzeniami (redundancjami).  Np. nasze dane są powielane na każdym rachunku, fakturze czy podaniu. Każdy z tych dokumentów żyje własnym życiem, nie jest połączony “sznureczkiem” relacji z naszym dowodem osobistym. Oprogramowanie, jeżeli ma odwzorowywać nasze otoczenie,  powinno zachowywać  się tak samo.

Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej “dziedziny”, to z dużym prawdopodobieństwem powstanie “coś co nie koniecznie jest tym czymś co powinno powstać”, i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci.

W naszej rzeczywistości praktycznie zawsze “wszystko ma swoje źródło”, jest to z reguły “jedno źródło” stanu rzeczy. W związku z tym podobnie powinno to wyglądać w oprogramowaniu (model dziedziny) i tu pojawia się “zasada pojedynczej odpowiedzialności”, którą warto stosować także w projektowaniu oprogramowania.

Czemu o tym tu piszę? Bo w zasadzie wynik analizy biznesowej to opis tego “jak ten świat u klienta funkcjonuje” i im wierniej go odwzorujemy i opiszemy, tym większa szansa, że powstanie “dobre oprogramowanie”. Poniżej kilka słów na ten temat z perspektywy programisty, czyż to nie (prawie) to samo?

Wczoraj mówiliśmy o single responsibility principle (SRP) czyli o zasadzie pojedynczej odpowiedzialności. Jest to zasada, która moim zdaniem najwięcej zmienia w dotychczasowych przyzwyczajeniach programistycznych. Na początku jest trochę męcząca ponieważ zgodnie z nią w klasie nie powinniśmy tworzyć innych obiektów.

Jak to? Nie mogę używać słowa kluczowego new? Nie mogę tworzyć obiektów?

No właściwie to nie. Jeżeli chcesz w klasie tworzyć obiekty to to już jest odpowiedzialność. Wiec klasa nic poza tworzeniem obiektów nie powinna robić. Ale przecież klasa która nie robi nic poza tworzeniem obiektów to fabryka. Wszystko jak najbardziej się zgadza. Fabryka ? wzorzec kreacyjny (hm? a może znacie jakieś bardziej odpowiednie słowo) gangu czterech. (za Single Responsibility Principle ? ciąg dalszy | @rek online | Arkadiusz Benedykt).

Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model…

Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji “nowa faktura”, model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający “w sobie”  wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają… Wnikliwym, polecam poznanie stylu projektowania o wdzięcznej nazwie [[Domain Driven Design]].

Polecam także artykuł: Czym jest to co modelujesz…