Niedawno napisałem:

oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podoba mi się klasa Pracownik?).

To stały temat wielu dyskusji z programistami. Ostatnio, po pewnym szkoleniu, w ramach wsparcia po szkoleniu jakie zawsze świadczę, znowu padło pytanie:

Czy zdarza Ci się robić analizy/projekty, gdzie byty występują pod nazwami innymi niż używanymi potocznie przez Biznes.

Z tym – używane pojęcia – jest regularnie duży problem, dlatego od pewnego czasu ortodoksyjnie stosuję budowanie “przestrzeni pojęciowej” dla projektu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słownik pojęć, listę reguł biznesowych (to nie to samo co reguły decyzyjne) oraz tak zwany diagram faktów, który służy do testowania (i dokumentowania słownika) – upewnienia się, że pojęcia nie kolidują ze sobą a ich definicje nie nakładają się na siebie oraz, że lista jest dziedzinowo kompletna. Po co to? Właśnie po to,

by żadne zdefiniowane słowo nie miało w projekcie (w wymaganiach, w kodzie) więcej niż jednego znaczenia i by znaczenie każdego zefiniowanego pojęcia nie budziło żadnych wątpliwości

(co nieco o słownikach terminów: Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć).

Jedna  uwaga na początek: jeżeli “byty” (klasy) w kodzie (projekcie) oprogramowania występują pod innymi nazwami niż w rzeczywistości, to jest to absolutna porażka, bo programista zupełnie traci kontakt z klientem i (lub) dokumentacją opisująca wymagania. Jeżeli już koniecznie programista musi ulżyć sobie w ambicji używania wyłącznie j.angielskiego w kodzie, powinien ten kod być bogato komentowany, by nie było wątpliwości jakie znacznie niesie np. nazwa klasy czy atrybutu (tym bardziej, że np. słowo name to nie tylko nazwisko…..)

Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji,  bo nie raz (a w zasadzie zawsze ;))  biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).

Pamiętam projekt, w którym wiceprezes pewnej firmy na każde działanie takie jak nowa umowa, nowy projekt,  nowy klient, używał słowa “temat”, nikt nie miał odwagi powiedzieć mu, że nie raz nie rozumie o czym on mówi … Ja – obcy – się odważyłem 🙂 i uporządkowaliśmy to, był opór ;). Pamiętam, że dyplomatycznie poprosiłem go by zbudował hierarchię “tematów” nazywając każdy element tej hierarchii jednym lub dwoma słowami słowami i pomogło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapoczątkował bardzo ciekawe podejście, ono się rozwija. Co ciekawe Evans nie wymyślił idei a system wzorców DDD. Wspólny język to dwa elementy: używanie biznesowych nazw (bez skrótów) na elementy rzeczywiste i klasy w systemie, ale także używanie np. pojęcia “fabryka” przez biznes i przez developera jako “kontener” na pewien rodzaj kompetencji (wiedza o tym jak powstają pewne obiekty biznesowe).

Elementy wzorca DDD to nie tylko bloki kodu, to także elementy (klasyfikatory) wiedzy o biznesie. Faktura VAT to agregat – struktura informacji, to tylko wiedza o tym co ten dokument zawiera, ale FabrykaFaktur to odrębna wiedza o tym jak ten dokument jest tworzony. Należy świadomie udokumentować oba byty: dokument i recepta jego tworzenia. Dlaczego osobno? Bo po pierwsze wystawione faktury żyją własnym, życiem i obciążanie każdej z nich (np. tysiąc faktur miesięcznie) całą wiedza jak powstała nie ma większego sensu. Po drugie zmiana przepisów nie powinna się odbić na dokumentach już wystawionych ani dociążyć nowo powstających.

Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.

Czy Model dziedziny ma stan?

(to część bardziej techniczna)

W kwestii czegoś takiego jak Stan Modelu w MVC (czy model biznesowy ma stan?) jestem ostrożny z używaniem pojęcia “stan”, popatrzmy na gry komputerowe… Czym jest stan?  Stan na pewien moment w czasie (snapshot) czy stan “biznesowy” trwający minuty, godziny a nie raz dłużej? Model to system: zespół elementów współdziałających. Z perspektywy biznesu, reaguje on na akcje (stabilny ekran oczekiwania na OK, to permanentny maszynowy przebieg sprawdzania stanu przycisków). Osobiście traktuję klasy Modelu jako samodzielne żyjące byty, konstrukcja metod musi zagwarantować brak błędów i radzić sobie z tym co “stałe” dla użytkownika i “zmienne” dla systemu (zegar bez sekundnika jest z perspektywy minut martwym przedmiotem a mimo to “chodzi”).

Podejście do MVC, które praktykuję: Model powinien realizować 100% funkcjonalności i dać się testować bez warstwy V i C. Konkretnym stanem  raczej charakteryzuje się konkretny obiekt a nie cały system. Cały system można zapewne opisać maszyną stanową ale po co, skoro są ich niezliczone ilości? Model żyje jak mrowisko, wystarczy zrozumieć mrówki, mrowisko to skutek na który za bardzo nie mamy wpływu.

Model DDD “analityczny” to metamodel implementacji, Evans traktuje go jako “bloki kodu”  zrozumiałe przez biznes, idąc dalej: analityk traktuje DDD jako wiedzę o biznesie w postaci zrozumiałej przez developera. Obie strony uznają, że ta struktura jest wzajemną “umową”. Jestem zwolennikiem takiego podejścia do DDD :), Evans się z tym w moich oczach nie kłoci, on w zasadzie nie pisał o analizie biznesowej :). Wielu programistów, autorów  doskonałych książek, zakłada, że “analizę wymagań ma poprawnie wykonaną”, co by to nie miało znaczyć :), ale to ogromne uproszczenie bo tu – błędy – tkwi większość ryzyk projektu.

Więcej o słownikach i regułach biznesowych:

(OMG, Glossary, Business Rules, http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules oraz http://en.wikipedia.org/wiki/Business_rule, http://www.visual-paradigm.com/support/documents/bpvauserguide/2017/2181/57043_creatingfact.html).