W ciągu ostatniej dekady miałem okazję pracować w kilku firmach, nad kilkunastoma projektami i poznać pewnie setki osób. Na początkowych etapach kariery skupiałem się na zrozumieniu technologii i wymagań oraz dowożeniu na czas. Zdecydowanie warto było poświęcić na to czas i doszlifować umiejętności programistyczne i wzbogacić swój narzędziownik w różne wzorce, rozwiązania i techniki, z których dzisiaj z większą łatwością przychodzi mi korzystać.
Później zacząłem coraz bardziej zagłębiać się w to, co tak naprawdę w danym projekcie/produkcie chcemy osiągnąć jako zespół. I tak, ze stricte wykonawczego spojrzenia (co mam zakodować) przeszedłem do próby bardziej wysokopoziomowego, mniej technicznego zrozumienia problemu, z jakim boryka się klient.
Szczególnie tej wiedzy nabrałem w pracy z mniejszymi, dynamicznymi firmami, których sukces w ogromnej mierze zależy od tego, jak zostaną odebrane przez pierwszych klientów na rynku.
Żyjemy w czasach bardzo dynamicznie zmieniających się technologii, rozwoju AI i narzędzi wspierających pracy programisty. Dodatkowo, na osoby nietechniczne czeka cała masa systemu typu low-code i no-code, która pozwala na coraz większe i złożone rozwiązania bez znajomości programowania. W związku tym, warto, aby software developer, miał w zanadrzu dodatkowe umiejętności, które wykraczają poza “rozmawianie” z komputerem.
Czym jest Domena
Zrozumiałem, iż aby być dla swojego projektu, kimś więcej niż tylko “klepaczem kodu” i wspierać klienta w podejmowaniu adekwatnych decyzji, istotne jest zrozumienie domeny, w której tworzone przez nas oprogramowanie ma funkcjonować. Umiejętność ta może być szczególnie istotna w dobie narzędzi low-code / no-code czy też rozwiązań AI generujących kod za nas.
Przez domenę mamy na myśli obszar gospodarki, czy rynku, w którym operować ma nasze rozwiązanie. Przykładem może być domena księgowości, jeżeli tworzymy oprogramowanie dla księgowych czy przedsiębiorców lub domena logistyki, jeżeli nasz produkt dedykowany jest dla firm spedycyjnych.
Dzięki zagłębieniu się w meandry danej domeny jesteśmy w stanie lepiej zrozumieć, w jaki sposób pracują docelowi użytkownicy, czego potrzebują, a także na jakie problemy możemy się natknąć podczas tworzenia rozwiązania.
Domain Driven Design
Jednym z coraz bardziej popularnych podejść do wytwarzania i modelowania oprogramowania, jest zapoczątkowane przez Erica Evansa, Domain Driven Design. Mimo iż sama książka Erica ma już ponad 20 lat, to właśnie ostatnie kilka lat mocno spopularyzowało jego podejście.
Domain Driven Design traktuje o postawieniu domeny w centrum projektowania naszego oprogramowania, poświęceniu jej najwięcej uwagi, aby odpowiednio zamodelowany fragment rzeczywistości, który przelewamy do kodu, był zrozumiany zarówno przez techniczną, jak i nietechniczną część zespołu wytwórczego. W taki sposób, jako programiści jesteśmy w łatwiejszy sposób pracować nad funkcjonalnościami z naszym product managerami, ekspertami domenowymi i innymi osobami, których zadaniem nie jest rozumienie kodu. Dzięki temu operujemy tym samym “wszechobecnym” (z ang. ubiquitous) językiem, a wymagania biznesowe mogą być o wiele bardziej czytelnie odzwierciedlone w rozwiązaniu jakim jest oprogramowanie.
W ramach Domain Driven Design możemy spotkać zarówno aspekty aplikowalne na poziomie kodu, jak i bardziej wysokopoziomowo, przy modelowaniu systemu czy też pozyskiwania i analizowania wymagań. W przypadku kodu mówimy o taktycznym DDD, gdzie do dyspozycji mamy szereg wzorców przenaszalnych do naszego systemu niezależnie od języka czy frameworka. Pozwala nam to na tworzenie systemów o dobrze opisanej i zbliżonej do siebie architekturze aplikacyjnej, których zrozumienie przez kolejnych programistów będzie łatwiejsze i przysporzy mniejszego wysiłku przy modernizacji czy też utrzymaniu.
Jeśli zaś chodzi o elementy wyższego poziomu, “nie dotykających” naszego kodu to nazywane one są strategicznym Domain Driven Design. Znajdziemy wśród nich aspekty skupiające się na przestrzeni problemu, podziału domeny na mniejsze elementy i budowaniu modelu systemu w oparciu o odpowiedni język, który to został wyłoniony przy współpracy osób technicznych z ekspertami domenowymi (osobami, które są dla nas źródłem wiedzy biznesowej w danej domenie).
Modelowanie
Podczas początkowej pracy nad oprogramowaniem istotne jest zebranie, jak największej wiedzy na temat procesów, które przyjdzie nam automatyzować. Oczywistym jest, iż zbieranie wymagań od osób na co dzień niezwiązanych z wytwarzaniem systemu może być trudne i czasochłonne. Na szczęście z pomocą przychodzą warsztatowe metody pracy z ekspertami domenowymi. Jednymi z nich są: Event Storming i Domain Story Telling.
Pierwsza z nich, stworzona przez Alberto Brandoliniego, skupia naszych akcjonariuszy na wspólnej sesji. Podczas niej, przy facylitacji osoby zaznajomionej z techniką, zaproszeni przyklejąją kolorowe karteczki reprezentujące zdarzenia na wspólną tablicę. Zgromadzona w ten sposób wiedza, jest następnie grupowana w procesy i doprecyzowana. Dzięki temu otrzymujemy mapę procesów w naszym systemie, pogrupowanych w subdomeny wraz z aktorami w nie zaangażowanymi i komentarzami na temat punktów krytycznych i możliwości. Jest to niewątpliwie bardzo skuteczna technika, z drugiej zaś strony dość kosztowna pod względem czasu i zaangażowania sporej grupy uczestników.
Alternatywnym sposobem może być zastosowanie Domain Story Telling, którego autorami są Henning Schwentner i Stefan Hofer. Stworzona przez nich technika przesuwa odpowiedzialność za tworzenie modelu w dużej mierze w stronę technicznego facylitatora.
Zapraszając na sesję gości, organizator poprzez zadawanie pytań i prostą notację piktogramową tworzy wizualizację procesów, jakie zachodzą lub mają zachodzić w systemie. W kolejnych krokach model jest doprecyzowywany przez przedstawianie efektów swojej pracy zaproszonym oraz dopytywaniem i klarowaniem niejasności. Ten tryb pracy z pewnością bardziej przypadnie do gustu w sytuacji gdy nie chcemy nadto angażować osób, od których to wymagania chcemy wyłuskać.
Wykorzystanie gotowych wzorców
Kolejnym niezwykle ważnym elementem, który ułatwia pracę przy zrozumieniu domeny i jej poprawnym zamodelowaniu, a następnie zaimplementowaniu, są archetypy modeli biznesowych. Oczywistym jest, iż wiele systemów rozwiązuje ten sam problem, czasem choćby w ten sam sposób, być może z naciskiem na inne aspekty (szybkość działania, globalna dostępność, user experience itd.). Nic dziwnego, iż spora część modelowanej logiki biznesowej powtarza się w wielu systemach.
Weźmy na przykład platformy e-commerce. W każdej z nich spotkamy się z listą produktów, koszykiem czy też zamówieniem. Poza detalami, mówiącymi nam o tym co sprzedajemy, jak wygląda dostawa i w jaki sposób weryfikujemy dostępność, na pewnym poziomie abstrakcji, nasze modele będą takie same lub bardzo podobne.
Nie jest to w żadnym wypadku moje odkrycie (mimo iż bym chciał), tylko spostrzeżenia mające już kilkadziesiąt lat. Sporą liczbę tego typu wzorców, nazywanych archetypami, znajdziemy w literaturze, chociażby w “Enterprise Patterns and MDA” autorstwa Neustadt, Arlow, którzy to jeszcze w czasach świetności i popularności UML-a spisali wzorce dotyczące zamówień i sprzedaży, osób i organizacji czy też inwentaryzacji. Mając do dyspozycji sprawdzone już przez dziesięciolecia archetypy, jesteśmy w dużo prostszy sposób stworzyć kolejny system logistyczny, magazynowy i wiele innych.
Narzędziownik modelarza
I tak od roli typowego klepacza instrukcji warunkowych, klas i funkcji, zafascynowanego kolejną biblioteką czy frameworkiem, przeszliśmy do roli osoby, która uzbrojona w Domain Driven Design, metody pozyskiwania informacji w dzięki Event Storming’u czy Domain Story Telling’u oraz świadoma re-używalnych i powtarzających się archetypów modeli biznesowych, staje się niejako modelarzem.
Wraz z kolejnymi funkcjonalnościami, modułami i projektami, które programista będzie rozwiązywał również na poziomie domenowym, korzystając ze swojego narzędziownika, jego wiedza na temat biznesu będzie rosła, a zauważanie reużywalnych wzorców na poziomie wyższym niż kod pozwoli na tworzenie rozwiązań lepiej zrozumianych i spójnych, w krótszym czasie.
Wartości dodane
Mimo iż początkowo wydawać się może, iż dodajemy kolejny poziom skomplikowania, a co za tym idzie, wydłużamy czas wytwarzania, prawda jest zgoła inna. Zbudowanie warstwy modelu, który jest zrozumiany przez obie strony, techniczną i biznesową, poprawi komunikacje i wyeliminuje wiele nieporozumień, które mogłyby skutkować lawiną błędów.
Dodatkowo, mając jasno zdefiniowany model, staje się on również swego rodzaju dokumentacją techniczną, która w połączeniu z dobrze nazwanymi scenariuszami testowymi, da nam świetny punkt wejścia dla nowych osób do naszego systemu.
Dla samego programisty, zdobycie umiejętności modelarza, daje ogromne możliwości na rynku. Zmieniając projekt lub firmę i wchodząc w nową rolę jest dużo łatwiej zrozumieć biznes i system go reprezentujący. Programista-modelarz dużo szybciej odnajdzie się w nowych projektach znajdując powtarzalne i wcześniej występujące wzorce, nie tylko na poziomie kodu, ale również na poziomie domeny biznesowej.
Podsumowanie
Biorąc pod uwagę zmieniające się podejście do programowania, wspomagane przez narzędzia wykorzystujące AI, rola programisty również ulega zmianie. Warto w tym wypadku rozwijać dodatkowe umiejętności, które dają szersze spojrzenie oraz zwiększają wartość na rynku. Być może, nasze umiejętności modelarskie okażą się w przyszłości o wiele bardziej cenniejsze niż znajomość języka programowania.
Zdjęcie główne artykułu pochodzi z envato.com.
