Jak przekonać biznes do wprowadzenia DDD w istniejącym produkcie?

W istniejącym i rozwijanym produkcie bardzo trudno zmienić niewygodną rzeczywistość, a zespołowi developerskiemu, który chce wprowadzić DDD (Domain Driven Design) trudno będzie to zrobić bez pomocy biznesu. Jak więc go zaangażować? Poniżej kilka sugestii, które mogą pomóc.

To DDD or not to DDD

Dobrze zacząć od własnego developerskiego podwórka i potwierdzenia wewnątrz zespołu, że to słuszna droga.

Gdy system jest nietuzinkowy, skomplikowany i ma wiele przypadków użycia, warto zmierzyć, czy można go rozwijać w tym podejściu. Najprostszy przepis znajdziemy w książce Implementing Domain-Driven Design Vaugha Vernona.

Dobrym pomysłem jest też skorzystanie z doświadczenia uczestników technicznych meetupów na temat DDD, bo być może startowali w tym samym punkcie i chętnie podzielą się wiedzą i doświadczeniami.

Ważne, aby zwrócić uwagę na dostępność ekspertów domenowych naszego klienta. Jeśli nie będą gotowi i chętni na ciągłą współpracę, trudno będzie stworzyć wspólny język i wydajnie zdobywać wiedzę do zbudowania poprawnego modelu. Jeśli pracujemy z klientem w Scrumie lub innych metodykach zwinnych z pewnością będzie to możliwe. Waterfall utrudni bądź też uniemożliwi pracę w DDD i tutaj byłaby konieczna najpierw zmiana systemowa.  

Wewnętrzne szkolenie ze zbierania wymagań i modelowania z użyciem Event Stormingu

Przećwiczenie całego procesu, począwszy od zebrania wymagań do zakończenia implementacji wybranego MVP, pozwoli zweryfikować zdobytą wiedzę teoretyczną w praktyce. Pojawia się zrozumienie tematu, przychodzi większa pewność siebie, ludzie są wiarygodniejsi w dyskusji z biznesem.

Można spróbować stworzyć w kontrolowanym środowisku Proof of Concept (PoC) dowolnego wyimaginowanego produktu (np. aplikacji dla korporacji taksówek).

Oczywiście nie wystarczy skupiać się tylko na trenowaniu technicznych aspektów tworzenia. DDD to nie tylko agregaty, sagi, commandy, eventy i inne technikalia. Zdarza się, że to musi wystarczyć, ale to tylko tzw. DDD Lite, pozbawiony głównej siły napędowej - wiedzy biznesowej zdobytej bezpośrednio od klienta.

Na pomoc przychodzi nam Event Storming. Ten treningowy workshop Alberta Brandoliniego pozwoli nam praktycznie sprawdzić użyteczność tej metody i przygotować się do jej zastosowania z biznesem.

Warto zrobić eksperyment z dwoma zespołami. Jeden zbierze wymagania i stworzy PoC w tradycyjny sposób, a drugi z użyciem Event Stormingu i DDD. Jeśli skomplikowanie domeny będzie na odpowiednio wysokim poziomie, z pewnością dojdziemy do ciekawych wniosków - z korzyścią dla DDD. Może się na przykład okazać, że Time to Market wybranego MVP jest krótszy niż jego odpowiednika stworzonego bez użycia DDD. Czasem okazuje się, że nie trzeba kończyć całej funkcjonalności, bo jej pewna mniej zaawansowana forma jest już wystarczająca.

Zbieranie wymagań z użyciem ES jest ekstra wydajne. Mając do dyspozycji wiedzę odpowiednich specjalistów (tzw. ekspertów domenowych) i zadając odpowiednie pytania, developerzy uczą się o wiele szybciej niż poprzez wymianę maili i czytanie dokumentacji. Bezpośredni kontakt skraca też czas przestojów w developmencie w oczekiwaniu na ustosunkowanie się ekspertów klienta do zadanych pytań.

Wykorzystanie „laboratoryjnego” modelu do stworzenia aplikacji

Co równie ważne, efektem zbierania wymagań jest model, który można przełożyć na implementację prawie bez zmian. Pozwala to szybciej rozpocząć pisanie kodu, a im wcześniej zaczniemy go pisać, tym wcześniej możemy przedstawić klientowi efekty i zweryfikować poprawność. Oczywiście nie musimy się bać spisywania wiedzy w dokumentach, mailach czy firmowej wiki. Trzeba mieć jednak świadomość, że to tylko tymczasowa forma dokumentacji. Docelowym źródłem wiedzy będzie nasz produkt i jego implementacja.

Na tym etapie developerzy zapewne docenią wysoką dostępność ekspertów domenowych. Nawet podczas tworzenia „eksperymentalnego” produktu ciągła komunikacja, przekazywanie wiedzy i weryfikacja wytworzonych elementów znacznie skracają czas developmentu i pozwalają uniknąć wytworzenia błędnych lub bezużytecznych funkcjonalności. Na tym etapie warto także rozwijać wybraną część treningowego systemu dwoma ścieżkami, żeby móc porównać np. czasy realizacji, użyteczność, czy zbadać jakość ostatecznego rozwiązania i to, czy odpowiada założeniom klienta.

Przygotować się na dyskusję z biznesem

Na koniec warto zebrać w formie prezentacji wady i zalety DDD i - o ile to możliwe - poprzeć je doświadczeniami z własnych workshopów, czy też tymi zaczerpniętymi od innych praktyków DDD. Istotne jest zaakcentowanie tych elementów procesu, gdzie zaoszczędzi się czas i pieniądze. Nie można jednak pomijać aspektów metody DDD, które niosą ryzyko podniesienia kosztów.

Dobre przygotowanie się do dyskusji i pokazanie zaangażowania zespołu w praktyczne potwierdzenie teoretycznych założeń upewni biznes, że nie są to tylko kolejne życzenia zespołu powstałe na fali jakiejś „mody”, tylko realny sposób na ulepszenie biznesu.

Praktyka z biznesem

Nic nie przekonuje bardziej niż własne doświadczenie. Dlatego też opłaca się przeprowadzić z biznesem szkolenie ze zbierania wymagań za pomocą Event Stormingu. Można powtórzyć swój własny eksperyment z wyimaginowanym produktem lub wykorzystać realny problem z domeny biznesu. Nie zawsze konieczne jest doprowadzenie tworzenia modelu do etapu agregatów, czasem wystarcza opisanie procesu za pomocą eventów.

Już na tym etapie mogą pojawiać się korzystne aspekty takiej formy zbierania wymagań - nie wspominając o tym, że budujemy relację z klientem, poznajemy docelowych użytkowników naszego produktu oraz pomagamy im w realny sposób rozwiązać ich problemy i ułatwić im pracę.

Dostarczyć coś na produkcję

Jeśli wspólnie z biznesem pracujecie aktualnie nad nową, wymagającą częścią produktu i utknęliście na etapie zbierania wymagań, warto spróbować pchnąć temat do przodu za pomocą Event Stormingu. W większości przypadków biznes jest zadowolony z takiej formy. Widzi zaangażowanie programistów i to, że zaczynają komunikować się językiem biznesu, a nie technikaliami.

Jest też namacalny efekt zbierania wymagań. Oprócz wiedzy w głowach uczestników, mamy gotowy graficzny model, który można zacząć implementować. Po dostarczeniu na produkcję korzystne byłoby znalezienie czasu dostarczenia części systemu o analogicznym stopniu skomplikowania w przeszłości. Dzięki temu można potwierdzić lub obalić założenia.

The End

Przedstawione powyżej sugestie są krótkim podsumowaniem doświadczeń we współpracy z klientami. W niektórych przypadkach DDD służyło tylko i wyłącznie w zakresie wzorców taktycznych, innym razem jako metoda tworzenia Core Domain dużego systemu.

U nas DDD służy zespołom w budowaniu wzajemnego zrozumienia z biznesem. Ustalenie wspólnego języka, znalezienie właściwych ekspertów domenowych i określenie jasnych granic wewnątrz produktu, w których dany język jest jednoznaczny, nie jest czymś trywialnym, ale efekty wynagradzają włożony wysiłek. I dla tych efektów warto przekonać biznes do tego, by wspólnie pracować z użyciem DDD nad Waszymi produktami.