środa, 20 listopada 2013

Style programowania (myślenia)

Jeżeli zajmujesz się programowaniem, to na prawdę powinieneś/powinnaś obejrzeć tę prezentację: http://www.infoq.com/presentations/style-methodology

Jak często zastanawiasz się nad sposobem myślenia o problemie, który implementujesz?
Dlaczego posługujesz się tym sposobem? Czy robisz to świadomie?

Czy to, że był to ulubiony sposób myślenia o problemach twórcy danego języka programowania (pierwszego jaki poznałeś/poznałaś) i został przez tegoż twórcę "zamrożony" w składni języka jest wystarczającym powodem?

Autorka prezentacji zadaje wiele ciekawych pytań.


Od siebie dodam, że z obserwacji setek programistów i programistek wyłaniają się pewne wzorce. Generalnie każdy z nas ma pewne standardowe "modele wewnętrzne", których używa do wyobrażania sobie problemów:
  • linijki kodu
  • przepływ danych
  • przepływ sterowania (np podane w prezentacji "rurki")
  • kształty na płaszczyźnie
  • ruchome kształty w przestrzeni
  • itd
a co za tym idzie każdy ma swoje kryteria estetyki, jakich stosuje podczas oceny rozwiązania, np:
  • zwięzłość - jeżeli myślisz linijkami kodu, to będziesz szukać zwięzłych języków, barokowa składnia przeładowuje Twą pamięć
  • harmonia - jeżeli wyobrażasz sobie kształty (język będzie nieistotny - odwrotnie niż w poprzednim przypadku)
  • znalezienie ogólnych modeli (np generalne klasy - oczywiście z masą statusów:) - jeżeli lubisz uogólniać
  • znalezienie szczegółowych modeli (np. wiele osobnych klas) - jeżeli lubisz różnicować
  • eksploracja słownictwa domenowego
  • przejście w abstrakcje (np. mapy i operacje na kolekcjach zamiast operacji domenowych)
  • itd...

Po latach zrozumiałem też, że próby oceny/krytyki kodu nie mają sensu, jeżeli posługujesz się innymi kryteriami estetycznymi niż jego twórcy.

Stawia to również pod znakiem zapytania Agileową wspólnotę kodu. Bo co jeżeli każdy, kto "udziela" się w danym fragmencie kodu chce dobrze ale każdy inaczej rozumie dobrze a przez to "ciągnie" design w swoją stronę? Powstaje to co zwykle... wielka... kupa... błota;)

//===============================

Osobiście nie jestem teoretykiem języków tak jak autorka prezentacji, dlatego z najbliższym poście z serii DDD h4x przedstawię klasyfikację bazowych building blocks (bardziej ogólnych BB z DDD), które może wykorzystać z powodzeniem każdy, nie koniecznie stosując DDD jako takie.

czwartek, 14 listopada 2013

JUG: 19-20 listopada Trójmiasto - DDD i testowanie

W imieniu swoim jak i Rafała zapraszam na warsztaty jakie będziemy prowadzić w przyszłym tygodniu w Gdańsku w ramach JUG korzystając z gościnności Spartez:

Modeling Whirlpool - warsztaty z modelowania DDD: https://www.eventbrite.com/e/modeling-whirlpool-warsztaty-z-modelowania-ddd-sawek-sobotka-tickets-9324093615

Jak wyprowadzić słabe i smutne testy na prostą: https://www.eventbrite.com/e/jak-wyprowadzic-sabe-i-smutne-testy-na-prosta-rafa-jamroz-tickets-9324528917

niedziela, 10 listopada 2013

DDD h4x: stosowalność DDD - czyli czy i kiedy DDD może mi w czymś pomóc

O serii


Niniejszy post jest pierwszym z serii DDD h4x poświęconej specjalnym technikom i hakom stosowanym w DDD.

Ostatnie dwa lata spędziłem na intensywnej pracy związanej głównie z wdrażaniem różnych form DDD w różnych organizacjach (stąd zmniejszona aktywność na blogu). Przymierzając się do zebrania doświadczeń w formie książki postanowiłem podzielić się obserwacjami i przemyśleniami z czytelnikami bloga oraz poddać je dyskusji w celu destylacji esencji.

Doświadczenia pochodzą z różnych aspektów, technicznej implementacji, uczenia technik, ale chciałbym skupić się przede wszystkim na samym modelowaniu.


Podstawowe pytanie: czy i kiedy?

Zaczniemy od podstawowego problemu: stosowalności DDD. Typowe pytania: czy DDD aplikuje się do w moim projekcie, jakie są ryzyka, co będę z tego miał, które problemy (właściwie, to nikt nie przyzna się, że ma problem, więc raczej: wyzwania) adresuje DDD, itd...

Każdy praktyk DDD odpowie Ci mniej więcej w ten sam sposób: stosuj DDD tylko dla systemów, które charakteryzują się znaczącą złożonością logiki domenowej, w których model domenowy jest krytyczny, ponieważ jest np. powodem tworzenia systemu, ponieważ np daje klientowi przewagę nad konkurencją.

Przykładowo: wyrafinowany model pozwala szybciej reagować na zmiany w biznesie, np szybciej definiować nowe produkty, analizować zachowanie klientów itd...

Często jednak zespoły nie posiadają jeszcze intuicji pozwalającej na "zmierzenie" złożoności.
Pojawiają się wówczas bezkontekstowe metryki typu: 30 use casesów (V. Vernon), 300 mandaysów, itd...
Bezkontekstowe metryki mają to do siebie, że są oparte o LWPzD (liczby wyciągnięte prosto z ... yyy dziupli).


Metryki:

Przechodzimy do meritum posta, czyli metryk, które uważam za miarodajne. Zatem, jeżeli zastanawiasz się nad wprowadzeniem DDD, to musisz sobie odpowiedzieć na kilka kluczowych pytań:

1. Jaka jest głębokość systemu? 


Pojęcie "głębokości systemu" jest metaforą, którą stosuję aby zorientować się co system "robi pod maską". Innymi słowy: ile kodu jest pomiędzy interfejsem systemu (graficznie ui lub jedynie api publikowane dla innych systemów) a infrastrukturą techniczną (np. jakimś rodzajem magazynu danych, sterownikami do urządzeń itd).

Przykładowo mamy ekran, klikamy w przycisk "OK" i co dzieje się wówczas "pod spodem". Czy następuje jedynie zebranie danych z  formularza, walidacja, proste kalkulacje i zapis. Jest to system klasy CRUD, czyli potocznie zwana "przeglądarka do bazy danych". System tej klasy charakteryzują się "płytką" (w sensie głębokości) logiką i zapewne nie ma tutaj miejsca na model domeny. Same ekrany są modelem domeny.

Innymi słowy: model mentalny problemu jaku użytkownik ma swej głowie, to co widać na ekranie i schemat bazy danych są tym samym.
Często spotykam się z systemami legacy, gdzie zaczęło się od niewinnej "powłoki wizualnej na relacyjną bazę danych" a w aktualnym stadium mamy do czynienia z agonią kolosa (stojącego na glinianych - bo krudowych - nogach).




Zupełnie inną "głębokość" będzie miał system, w którym przykładowo:
użytkownik klika "zatwierdź zamówienie" a pod spodem system: wylicza rabaty i kary, nalicza prowizje dla handlowców, steruje stanami magazynowymi i produkcją oraz integruję się z SAPem.
Złożoność tej logiki będzie wymagała zapewne nietrywialnego modelu.

2. Jaka jest relacja pomiędzy UI a modelem domenowym?


Na podstawie poprzedniego przykładu możemy sobie wyobrazić, że użytkownik nie maj pojęcia o większości operacji, które wykonują się w systemie gdy klika on przycisk "zatwierdź zamówienie".

Nie ma o nich pojęcia, ponieważ nie chcemy aby miał ich świadomość (szczególnie prowizji dla handlowca;)




3. Kto jest źródłem wiedzy: User czy Ekspert?


Dochodzimy tutaj do kolejnego kluczowego pytania. Tworząc model domeny będziemy rozmawiać z potencjalnymi użytkownikami czy może z kimś zupełnie innym - z kimś, to wie dlaczego system ma działać w ten sposób, ale sam nie koniecznie będzie operatorem systemu. W DDD osoby te grają rolę Ekspertów Domenowych. Oczywiście w szczególnym przypadku Ekspert może być również Operatorem.

Innymi słowy: czy potencjalny operator systemu ma świadomość złożoności biznesu, czy jedynie wykonuje swoje zadania/obowiązki i jest zadowolony z błogiej nieświadomości.

Przykładowo: najstarszy księgowy (Ekspert wydelegowany od strony klienta) objaśnia nam jak i dlaczego działa pewien proces, który modelujemy i implementujemy, ale użytkownik (np super junior consultant) będzie wpisywał na UI jedynie dane i klikał "procesuj'.

Nie chcę być źle zrozumiany: operator systemu jest ważny w całym procesie produkcji systemu, ponieważ jest źródłem wiedzy dla UX designera, który będzie się starał zapewnić mu ergonomię.


W projektach, gdzie nie mamy do czynienia z klientem (zewnętrznym lub wewnętrznym) i tworzymy produkt "na półkę" warto wyłonić rolę Eksperta Domenowego. Chodzi o to, aby aby twórca modelu nie był jednocześnie jedynym źródłem wiedzy o domenie, ponieważ może popaś w pułapkę "miłości do dziecka swego umysłu". Ekspert domenowy powinien być walidatorem modelu - czyli osobą nie będącą twórcą modelu.

4. Czy obiekty sterują światem, czy może są jedynie notatką ze stanu świata?


Na wstępie podziękowania dla jednego z uczestników szkolenia - Rafała O. który ujął tę metrykę zgrabne sformułowanie.

Możemy zadać sobie pytanie, czy obiekty z naszego modelu domenowego mają w sobie zamodelowane reguły sterowania światem zewnętrznym? Podejmują decyzje na podstawie reguł, które wyłoniliśmy podczas sesji modelowania z Ekspertem Domenowym.



Czy może są jedynie strukturami danych (nie obiektami w sensie OO), które są "notatką" na temat pewnego stanu świata zewnętrznego - system CRUD. Użytkownicy używają systemu jedynie do gromadzenia danych i ew. ich edycji, nie istnieją żadne reguły domenowe (jedynie prosta walidacja), zawsze można wszystko przeedytować.

Często pojawiają się pytania: "biznes sam przyznaje, że nie wie jak i dlaczego to ma działać" lub "biznes działa niezgodnie z modelem wynikającym z ustawy". W takim razie nasz model oddaje nie to jak powinno być w idealnym świecie, tylko to jak biznes działa. Chcemy przecież aby nasze procesory robiły to w taki sposób jak chce biznes a nie jak wyglądałoby to w idealnym świecie.

5. Co jest pierwsze: proces czy domena? 


Na ten temat pisałem w jednym z poprzednich postów: http://art-of-software.blogspot.com/2013/10/przyczyna-czy-skutek.html - komentarze są również ważne.

Rozpoczęcie modelowania od domeny a nie od procesu jest najważniejszą różnicą pomiędzy DDD a innymi podejściami. Widać to już podczas pierwszej sesji modelowania lub podczas dwóch pierwszych zadań warsztatowych. Różnice w modelach, które wyłaniają się z tych dwóch podejść są zasadnicze.

Czasem spotykamy się z problemem, gdzie nasze źródło wiedzy domenowej używa narracji z poziomu procesu a nie domeny. Możemy przekierować model mentalny takiej osoby odpowiednimi technikami lingwistycznymi i wizualnymi - o czym w kolejnych postać z serii DDD h4x.

Kluczowe jest też zrozumienie, że duże organizacje dążą do standaryzacji procesów, w celu zapewnienia sobie swobody w wymianie personelu. Zainteresowanych tematyką miękką zapraszam do lektury artykułu poświęconego modelowi rozwoju kompetencji braci Dreyfus: http://bottega.com.pl/artykuly-i-prezentacje#soft
Wniosek płynący z tego modelu jest następujący: na niższych poziomach kompetencji jesteśmy zorientowani na procesy, jedynie Ekspert rozumie dlaczego proces tak wygląda. Dlatego w DDD dążymy do kontaktu z Ekspertem Domenowym.

6. Jak długo będziesz utrzymywać system? 


Stosowanie technik DDD jest kosztowne, dlatego traktujemy je jako inwestycję (lub spłatę długu w systemach legacy).
Rozpoczynając nowy projekt musimy odpowiedzieć sobie na pytanie o perspektywę czasową. Na jej podstawie oceniamy czy warto inwestować czas w model, czy być może metodyka "kroczącego prototypu" będzie bardziej opłacalna.




Warunki dodatkowe

W uproszczonym kontekście możemy stosować podejście DDD Lite - posługujemy się wówczas jedynie wzorcami taktycznymi (building blocks), które zwiększają drastycznie jakość kodu i jego podatność na testowanie.

Natomiast dostęp do Ekspertów Domenowych (będących źródłem wiedzy i weryfikujących modele), wyłonienie roli Modelarza (biegłego w technikach DDD i posiadającego miękkie zdolności predysponującego go do tej roli) oraz podejście iteracyjne pozwalają nam na pełną implementację DDD.

W skali całego systemu

Klasy problemów technicznych


Wymienione metryki sprowadzają się do umiejętności klasyfikowania problemów i dobierania klasy rozwiązania do klasy problemu.
Chodzi tutaj o dobór klasy rozwiązania technicznego jak i metodyki (modelowania, zarządzania projektem).

W dużym systemie mamy zapewne do czynienia ze wszystkimi klasami problemów. Znakomita większość kodu systemu może sprowadzać się klasy problemu CRUD. Jednak kilka/kilkanaście procent może wymagać stosowania DDD.

Od architekta wymagamy umiejętności klasyfikowania problemów i oczekujemy znajomości wielu (a nie tylko jednego) stylów architektonicznych oraz doświadczenia w dobieraniu klasy problemu do klasy rozwiązania.

Trudne pytanie: jak sklasyfikować problem? Czy analiza wymagań niefunkcjonalnych wystarczy? Na pewno nie, dlatego architekt pownien być zaangażowany w modelowanie i implementację aby na podstawie wyłaniającej się złożności (np. głbokość systemu) projektować odpwoiednie rozwiązania.

Klasy problemów organizacyjnych


Podobnie część funkcjonalności mona zakwalifikować:

  • eksperyment - nie wiem czego nie wiem
  • pośrednie - wiem czego nie wiem
  • rzemiosło - wiem wszystko

Czyli: Agile, Lean, Waterfall.

Podejście DDD


W DDD zakładamy, że nie ma sensu (komercyjnego) stosowanie technik DDD na przestrzeni całego systemu. Dlatego wyłaniamy Core Domain (kilka/kilkanaście) procent systemu, gdzie stosujemy te techniki.

W tym miejscu stosujemy odpowiednią architekturę aplikacyjną (4-layers, CqRS, Ports&Adapters), a w innych modułach (crud) lepiej się sprawdzi jedna warstwa z np. mvc/mvp i scafoldingiem.

To w Core Domain inwestujemy w gęstą siatkę bezpieczeństwa testów automatycznych.