Cztery lata temu napisałem jeden z pierwszych swoich artykułów o wzorcu DDD, zwracałem uwagę na największą korzyść, jaką wnosi:
Czemu lubię i polecam styl DDD? Bo nawet jak nie znamy przyszłych zmian (nowych wymagań) to na pewno projekt będzie się dało rozbudować zamiast zmieniać. Dlaczego? Bo jeśli projekt dobrze ?modeluje? rzeczywistość to znaczy, że jeśli tylko coś zmieni się w tej rzeczywistości będzie możliwe to, do takiego samego odwzorowania w projekcie. (Domain-Driven Design ? nie metoda a styl?.).
Mimo tego, że brzmi to fantastycznie jest to prawdą. Tym razem wpis będzie bardzo krótki bo polecam do przesłuchania referat Sławka Sobótki (45 minut, ale polecam). Bardzo obrazowo mówi o analizie obiektowej. Polecam zarówno analitykom jak i programistom. Tym pierwszym by uczyli się analizy, tym drugim by nauczyli się pokory nadmiernie zawierzając użytkownikom na etapie analizy wymagań…
Dzięki za dobre słowo. Widzę, że licznik odsłon filmu zwiększył się o ok 100, więc gdyby ktoś potrzebował slajdów to są tutaj https://prezi.com/ihs7d0t_0mci/jak-wciagnac-eksperta-domenowego-w-wir-modelowania-wizualne-i-lingwistyczne-techniki-ddd/
To ja dziękuję, bo nie jestem sam :). Jak posłuchałem, to nie dość, że mi się kilka kolejnych klapek otwarło, to zrozumiałem z perspektywy problemów kodującego, dlaczego nie należy zawierzać „userom”. Ciekaw jestem twarzy Twojej widowni, bo w sumie Twoja (i takie jak ta) prezentacja obala mit „agile the best”. Owszem aplikacje o płytkiej (lub żadnej) logice biznesowej można robić prototypując z userem, ale wystarczy, że nagle prosty CRUD w rodzaju „Faktury sprzedaży” dostanie „strzał” w postaci „rabaty dla stałych klientów i promocje” i czar pryska… A bywałem świadkiem takich porażek… Tak więc Twoja prezentacja ma tu honorowe miejsce :).
Ja na co dzień pracuję z zespołami, które tworzą raczej „głębokie” aplikacje (przynajmniej niektóre moduły takie są) i nikt nie dyskutuje z podejściem DDD, każdy rozumie, że ma problem i trzeba go głębiej zrozumieć. Nie ma oporu i wojen religijnych, raczej nastawienie: co z tym zrobić:)
no to masz wyedukowane zespoły, ja też… czasami 😉
Powiedziałbym raczej „doświadczone bólem” i rozumiejące klasę problemu z jaką się zmagają. DDD dopiero się edukujemy.
Ale wynika to może też stąd, że jeżeli firma tworzy nietrywialne rozwiązania, to są one również zwykle bardziej intratne a przez to są środki na edukację i rozwój ludzi. Tak więc mogę mieć do czynienia z niereprezentatywną próbką z branży:) Z mojego punktu widzenia wszystkie firmy są rozsądne, świadome i patrzą perspektywicznie oraz stwarzają warunki aby nie tracić programistów (bo ci zwykle nie lubią rzeźbić w g;)
Z ostatnim zdaniem ja i wielu innych się nie zgodzi ;). Ja obserwuję, że firmy (zespoły) decydują się na szkolenie/zmianę metod pracy, gdy „benchmarking” (czytaj konkurencja) im pokaże, że ich „najlepsze pod słońcem zwinne metody oparte na relacyjnych bazach danych” (czyli te które stosują) jakimś dziwnym trafem dają znacznie większe koszty i dalsze terminy niż „inni”. Nagle przychodzi Prezes i mówi: „Panowi Krój jest nagi”.….
Hmm skoro już management musi pouczać develoeprów to… no, słabo.
Ja spotykam się z sytuacjami gdzie świadomość i potrzeba zmiany wychodzi oddolnie.
Tu nie chodzi o to, że management poucza developerów, chodzi o to, że management zaczyna porównywać koszt vs. efekt i zaczyna szukać przyczyn (znowu benchmarking z konkurencją).