Wiedza domenowa jest tematem, który tak naprawdę jest obecny w programowaniu od bardzo dawna. Jednak wraz z rosnącą w ostatnich latach popularnością Domain Driven Design stał się on szczególnie istotny. Czym zatem jest wiedza domenowa i czy jako programiści powinniśmy się nią przejmować?

A co to jest?

Najprościej mówiąc wiedza domenowa to po prostu znajomość biznesu, obszaru, dziedziny dla której powstaje oprogramowanie. Przykładowo jeżeli mówimy o projekcie dla banku to wiedzą domenową będzie wiedza na temat instrumentów finansowych obecnych w bankach, znajomość prawa bankowego czy ogólnie wiedza o finansach.

Wiedza domenowa obecna może być w dwóch grupach – w firmie zlecającej wykonanie systemu i w zespole pracującym nad aplikacją.

Pierwsza grupa jest oczywista. W firmie klienta znajdują się osoby, które mają wiedzę na temat biznesu, w którym firma działa. Potrafią rozwiać wątpliwości czy wyjaśnić jak jakiś proces działa. Prawie na pewno mają z tą dziedziną (domeną) do czynienia na co dzień. Miejmy przynajmniej taką nadzieję.

Druga grupa może wymagać wyjaśnień. Bo nie chodzi o to, że programiści są ekspertami w dziedzinie finansów, marketingu czy wędkarstwa. Chodzi o to, że znają ogólne procesy i potrafią korzystać z powszechnie używanych w danej branży pojęć. Nie muszą wiedzieć jak dokładnie liczy się stopy zwrotu z inwestycji w fundusze, ale jeżeli zobaczą we wzorze pojęcia takie jak „fundusz”, „wartość” czy „stopa zwrotu” to nie powinni uciekać w popłochu.

Po co mi ta wiedza?

Pewnie jako programista zastanawiasz się po co Ci ta wiedza. Po co właściwie miałbyś uczyć się tych pojęć skoro Twoim zadaniem jest po prostu pisanie kodu?

Odpowiedź jest tym bardziej oczywista im bliżej klienta przyjdzie Ci pracować.

Jeżeli Twoja praca wygląda tak, że łańcuszek analityków i product ownerów przepuszcza przez siebie każdą informację od klienta tak że na końcu dostajesz tylko dokument, w którym jest napisane „dodaj metodę A, która wyciąga połowę danych z tabeli X i liczy z nich wartość wg wzoru F” to pewnie taka wiedza za wiele Ci nie da. Ale też Twoja praca nie wymaga za wiele myślenia.

Komunikacja

Jednak im bardziej jesteś osobą mającą wpływ na projekt albo im więcej kontaktu masz z klientem tym bardziej doceniasz to, że znasz pewne pojęcia domenowe. Jeśli potrzebujesz dodatkowych informacji do zadania to w rozmowie z klientem albo ogólnie osobą wiedzącą co robicie nie będziesz siedział z dokumentacją i szukał każdego słowa jakie padnie. Byłoby to wielce nieefektywne. Znowu w drugą stronę taka osoba nie będzie się orientowała w kodzie. To nie jej interes jak zaprojektowaliście tabele czy klasy. Więc operowanie w rozmowie pojęciami na poziomie kodu nie da oczekiwanego efektu i zrozumienia. Tak jak jej odpowiedź nie będzie się odnosiła do klas czy tabel w bazie.

Jeżeli Twój zespół pisze kod zgodny z Domain Driven Design to pewnie spotkałeś się z pojęciem wiedzy domenowej, słownikiem pojęć czy jakimiś obiektami domenowymi. Ale jeżeli dopiero planujecie wdrażać takie podejście to wiedza na temat tego jak działa biznes klienta jest Wam niezbędna. Tylko w ten sposób da się zaprojektować optymalną strukturę kodu, która będzie pasowała do zadań jakie będzie wykonywać.

Ty decydujesz

Przykładowo w naszych projektach kontaktujemy się z klientem na bieżąco. Poza codziennymi spotkaniami z product ownerem są też cykliczne sesje z użytkownikami. Gdybyśmy na tych spotkaniach nie operowali podstawowymi pojęciami świata finansów to prawdopodobnie ich sensowność byłaby zerowa. Dlatego nasz klient poszedł o krok dalej i każdemu nowemu programiście w naszym zespole robi krótkie szkolenie z inwestowania i daje możliwość poznania procesów jakie za tym stoją i pojęć jakimi operują ich analitycy. Dzięki temu nie tylko umiemy się komunikować z nimi ale też wiemy dlaczego robimy te projekty i w jaki sposób będą one używane.

Przez to też mamy możliwość reagowania na pewne pomysły, które ogólnie mają sens, ale akurat w tym kontekście są niepotrzebne albo mogą być zrobione lepiej. To powoduje, że nie jesteśmy tylko wyrobnikami w fabryce ale też osobami, które mają wpływ na to jak wygląda efekt końcowy. Miałem nawet o tym prezentację na finałowej gali konkursu „Daj się poznać” w 2017 roku.

Skąd tę wiedzę brać?

Najczęściej wiedza ta bierze się z doświadczenia. Jeśli pracujemy przy 4 projekcie dla banku to jest duża szansa, że pojęcia są podobne więc i nasza wiedza przechodzi z projektu do projektu. To jest sytuacja kiedy zdobywamy wiedzę domenową pasywnie. Z tego powodu czasami zdarza się, że w ogłoszeniach o pracę wpisane jest „doświadczenie w podobnej branży”. Dzięki temu pracodawca może liczyć na to, że nie będzie Ci musiał tłumaczyć wszystkiego od początku.

Drugim sposobem jest ten, który jest obecny teraz u nas. Czyli klient decyduje się po prostu nas przeszkolić z tego czym się zajmuje. W obecnym projekcie mieliśmy to na wypasie. Pojechaliśmy na tydzień do siedziby klienta gdzie jego analitycy opowiadali nam o inwestowaniu. Ale również poprzedni klient zorganizował coś podobnego tylko na mniejszą skalę. Po prostu dostaliśmy jednodniowe wprowadzenie do bankowości, którą się zajmowali.

Ostatni sposób to aktywne zdobywanie wiedzy. Idealnie jeżeli studiowałeś albo studiujesz na kierunku związanym z branżą, dla której robicie projekt. Sytuacja bardzo rzadka  ale nie niemożliwa. W końcu czasami ludzie pracują w jednym zawodzie, a z ciekawości bądź konieczności studiują drugi. Wtedy masz ogromną przewagę jeśli chodzi o rozumienie tego po co robicie projekt i co się pod nim kryje. Ale nie musisz od razu iść na studia ekonomiczne żeby uczyć się o finansach. Czasami zdarza się, że jest to temat, który Cię po prostu interesuje i doczytujesz o nim po pracy. W takim wypadku również zdobywasz wiedzę domenową, a więc poznajesz procesy jakie się kryją za Waszą pracą.

Mówiąc ogólnie – warto interesować się też innymi tematami niż kod ;) O finansach wspominam tutaj nieprzypadkowo bo dużo projektów programistycznych jest z nimi związane.