Pierwsza litera w DDD reprezentuje domenę, czyli rzeczywistość danego problemu, tzw universe of discourse. Tę rzeczywistość można zamodelować: powstaje model domeny. Taki model można wyrazić, np. na diagramie. A zatem mamy do czynienia z trzema różnymi rzeczami: domena, model, diagram. W dodatku nie muszą one być w relacji jeden do jeden: jedna domena może mieć wiele modeli, z których każdy może mieć różne diagramy. Przedstawia to rysunek:

To, że diagram modelu ≠ model Evans podkreśla we wstępie do DDD kilkukrotnie, m.in. w takim fragmencie:

A domain model is not a particular diagram; it is the idea that the diagram is intented to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.

Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

Evans przypomina znaną prawdę, że reprezentacja rzeczy to nie jest rzecz. Tę samą, którą wyraził belgijski malarz René Magritte w swoim obrazie pt. Zdradliwość obrazów, na którym podpis pod fajką głosi: To nie jest fajka.

Autor tak komentował swoje dzieło:

The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it’s just a representation, is it not? So if I had written on my picture „This is a pipe”, I’d have been lying!

René Magritte

Niniejszy artykuł jest pierwszym z mini serii wpisów o tym jak przedstawiać modele (m.in. jak rysować ich diagramy). Chciałem więc zacząć od przypomnienia powyższych prawd i wyjaśnienia czym jest model.

Model pojęciowy

To, co Evans nazywa modelem domeny, ja określam modelem pojęciowym (ang. concept model)*. Jest to termin dobrze opisany w standardzie SBVR i znacznie bardziej precyzyjny. Definicja ze standardu jest następująca:

concept model – all of the concepts within a body of shared meanings, structured according to the relations among them.

Ja trochę parafrazuję tę definicję w sposób następujący:

model pojęciowy – uporządkowany zbiór pojęć (jednostek wiedzy) i relacji, które między nimi zachodzą.

Co to znaczy? W skrócie: mamy jakieś pojęcia (np. klient, produkt, magazyn), które mogą wchodzić ze sobą w relacje (klient kupuje produkt, magazyn pakuje produkt). Te pojęcia i relacje to są znaczenia: wyobrażenia, myśli, idee. Coś, co jest w naszych głowach i musi być ubrane w słowa, żeby dało się to zakomunikować.

Zebranie samych pojęć wiele nie wnosi. Trzeba je zorganizować, poukładać. Zwraca na to uwagę Evans w ww. cytacie. Jest to też wskazane w definicji. A zatem dopiero po dodaniu relacji uzyskujemy model (na marginesie: ludzie z powyższego rysunku muszą się dogadać, bo aktualnie mają niespójne połączenia w modelu).

Ty już masz model pojęciowy

Jeśli na co dzień pracujesz z innymi ludźmi nad jakimś zagadnieniem to na pewno razem ze współpracownikami macie w głowach to samo (lub zbliżone) rozumienie Waszej domeny. That’s it: macie już model pojęciowy.

Możecie nie mieć diagramów. Możecie nie mieć definicji pojęć. Możecie nie mieć słownika terminów. Ale jakiś model już istnieje. Potraficie się dogadać (lepiej lub gorzej) i coś razem zdziałać. Wszyscy się rozumieją – czasem może nawet bez słów – bo macie to samo w głowach.

Idealnym przykładem jest gdy dobrzy znajomi od lat grają w ulubioną grę planszową. Gdy po raz kolejny się spotykają, to nikomu nie trzeba ponownie tłumaczyć zasad. Ustawianie planszy, rozdawanie kart, rozkładanie pionków – to wszystko trwa bardzo krótko. Siadają i od razu grają. Bo wszyscy dobrze czują mechanikę gry. Nawet nie tyle że rozumieją: po prostu czują.

Wyzwania braku instrukcji

A co jeśli instrukcja do gry planszowej (lub naszego biznesu) się zgubi (lub nigdy jej nie było)? Ktoś powie, że to nic strasznego, bo i tak wszyscy potrafią grać w grę (robić biznes). A jednak rodzi to kilka wyzwań:

• Uczenie nowych osób: trudniej jest rozbudować zespół – doświadczeni pracownicy nie mają zwykle tyle czasu, by nowym kolegom przekazać całą wiedzę w rozmowach;
• Pamięć organizacyjna: czy na pewno dobrze wszystko robimy? czy nie pomyliliśmy zasad? koledzy starsi stażem już dawno odeszli więc nie mamy kogo zapytać czy dobrze rozumiemy, co zrobić w problematycznych sytuacjach;
• Ryzyko nieporozumień: czasem może się okazać, że jednak nie wszyscy rozumieją zasady tak samo a wtedy przestaje być różowo, pojawiają się konflikty, oskarżenia, frustracja.

Ostatni punkt jest najgorszy. Nie tylko jest dość częsty ale też może powodować przykre konsekwencje i rodzić realne koszty. Przykładami określeń, wokół których najczęściej rodzą się nieporozumienia, są:

• proces – czy chodzi o definicję procesu (np. proces zakupowy) czy o instancję procesu (np. proces zakupowy dla zamówienia nr 123)? Gdy klient zamawia u nas implementację nowego procesu to ma na myśli jedno. Ale gdy zgłasza na support problem z zakończeniem procesu to chodzi o coś zupełnie innego.
• klient – czy klient to osoba, która właśnie weszła na naszą stronę? Czy może ktoś kto założył konto? A może tylko osoby, które zamówiły i opłaciły usługę są klientami? To są pytania w przypadku gdy świadczymy usługi B2C. W przypadku B2B musimy jeszcze odróżnić naszego klienta (firmę, która kupuje usługi od nas) od klientów naszego klienta.
• projekt – to kolejne słowo wytrych, używane przez wszystkich na określenie prawie wszystkich działań w firmie. Jakie są jego granice? Kiedy się kończy? Czego dotyczy? Takie pytania pomagają zrozumieć czym projekt jest a czym nie.

Ryzyko nieporozumień w rozmowach na żywo jeszcze nie jest strasznie wysokie – można wnioskować znaczenie z kontekstu lub na bieżąco dopytać rozmówcę. Ale problem się potęguje gdy nadawca wysyła komunikat, który będzie konsumowany w jego nieobecności, np.:

• wiadomość wysłana na komunikatorze, gdy nadawca znika na pół dnia,
• zapis w umowie,
• pozycja w cenniku (np. w pakiecie X jest 10 procesów),
• zapis w bazie danych (np. liczba klientów wynosi 150).

Ostatni przykład na powyższej liście jest wyjątkowo groźny. Jeden zespół projektuje system informatyczny by zbierał i zapisywał jakieś dane. Inna osoba buduje na tych danych raporty. Na końcu inny zespół odczytuje raporty, mierzy KPI i podejmuje na ich podstawie decyzje. Czy oni wszyscy na pewno mają w głowach te same znaczenia? Tutaj ocieramy się o kwestię jakości danych.

Tworzenie reprezentacji jest trudne…

Załóżmy, że po lekturze poprzedniej części postanowiliśmy, że zgubioną instrukcję do gry trzeba odtworzyć. Okaże się wtedy, że jej spisanie nie jest wcale takie proste.

Weźmy osoby, które świetnie grają w grę i poprośmy ich o napisanie do niej instrukcji. Z pewnością każda zrobi to inaczej. Owszem: każda poprawnie opisze grę. Ale jedne opisy będą lepsze (zwięzłe, jednoznaczne, klarowne) a inne gorsze (zagmatwane, rozlazłe, niespójne). Co więcej: wcale nie będzie tak, że osoba, która w grę gra najlepiej, zrobi najlepszą instrukcję.

To trochę jak z fajką i jej obrazem. Nie każdy kto pali fajkę będzie umiał ją namalować.

… ale możliwe

Stworzenie reprezentacji modelu pojęciowego jest trudne ale to nie jest sztuka ani czarna magia. To rzemiosło, którego każdy może się nauczyć. W następnych artykułach spróbuję je przybliżyć.

Celem tego wprowadzenia było wyjaśnienie, że czym innym są prawdziwe obiekty, czym innym wyobrażenie o nich a czym innym jego reprezentacja. Właśnie dlatego na zdjęcie w tle do artykułu wybrałem trójkąt semiotyczny.

A zatem seria jest o malowaniu fajek a nie o ich produkcji. Możesz ją potraktować jak mini kurs rysunku 🙂