Cytaty #1

"People with strong technical backgrounds can covert any task into a technical task, thus avoiding work they don't want to do"

"By pretending the work is somehow abstracted from the people we can transform our interpersonal failure into a mechanical failure. It's much easier to say for example, 'We couldn't get the program working on time, than 'I wasn't skilled enough to help Jack become a better programmer'"

Te miażdżące cytaty pochodzą z książki: Becoming a Technical Leader: An Organic Problem-Solving Approach. 

DDD-Leaven v2

Po kilku nieprzespanych nocach opublikowaliśmy drugą wersję projektu DDD-Leaven
https://github.com/BottegaIT/ddd-leaven-v2

Podobnie jak w wersji 1, celem jest udostępnienie projektu, który pozwala szybko rozpocząć pracy z technikami DDD poprzez zapewnienie szkieletu technicznego (chciałbym w tym miejscu podkreślić nieoceniony wkład Rafała Jamroza).

Natomiast w wersji drugiej rozszerzyliśmy znacznie domeny biznesowe aby zilustrować techniki modelowania - zaawansowane wykorzystanie Building Blocks, ale przede wszystkich techniki lingwistyczne oraz techniki dokumentowania modelu i prowadzenia sesji modelowania z Ekspertem Domenowym.

Wiele z tych technik to implementacja lub nawet rozwinięcie technik, jakie poznaliśmy na wiosennym IDDD Tour wraz z eksperymentalnymi technikami rozwijanymi w ThoughtWorks.

Niektórych technik nie "widać" poprzez kod, dlatego będę je opisywał w kolejnych odcinkach serii DDD h4x.

Wiki jest w trakcie tworzenia, ale skalowalna "mapa" powinna pomóc w zwiedzaniu źródeł: http://prezi.com/akrfq7jyau8w/ddd-cqrs-leaven-v20/

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

Aby zacząć od konkretów technicznych: kilkanaście osób pytało o przykład implementacji założeń z tekstu: http://art-of-software.blogspot.com/2013/06/mapowanie-relacyjno-obiektowe.html
Teraz dysponuję źródłami, które mogę udostępnić: https://github.com/BottegaIT/ddd-leaven-v2/blob/master/src/main/java/pl/com/bottega/ddd/support/infrastructure/repository/jpa/GenericJpaRepository.java

Czasowniki głupcze!

Kilka dni temu mój brat zwrócił mi uwagę na ciekawe zjawisko.

/*
Dodam, że brat z wykształcenia jest dziennikarzem, pracuje jako redaktor w radiu i dodatkowo relacjonuje wydarzenia w naszej branży w dziale Planeta IT w programistamag.pl (próbka relacji z jPikniku: Java nad Wisłą)
*/

Otóż człowiek, który na co dzień zajmuje się komunikacją, przejrzał z ciekawości kilka moich artykułów oraz tekstów innych autorów technicznych i zapytał:
- Dlaczego Ty (Wy) używacie tak namiętnie rzeczowników, rzeczowników odczasownikowych i posługujecie się namiętnie równoważnikami zdań?
- ???
- No na przykład: dokonanie faktu wystawienia faktury przez księgowego zamiast: księgowy wystawił fakturę; częste występowanie błędu zamiast: błąd występuje często itd
- Hmm w sumie nigdy się nad tym nie zastanawiałem...

I co śmieszne: powiedziałem o tym niedawno kilku osobom podczas lunchu, pośmialiśmy się sami z siebie po czym każdy nieświadomie skomentował zjawisko przy pomocy form bezczasownikowych:P

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

Stare porzekadło mówi, że: język jakim mówisz determinuje sposób w jaki myślisz...
W jednym z najbliższych postów z serii DDD h4x przedstawię techniki lingwistyczne pozwalające na tworzenie behawioralnych modeli domeny (zorientowanych na czynności reguły nimi rządzące) zamiast anemicznych struktury danych wyrażonych przez rzeczowniki.

Celem będzie czytanie kodu niczym prozy, takiej w której pojawi się podmiot, orzeczenie, dopełnienie jak i nawet przydawka:)

Nowe serie artykułów: zaawansowany Android i refaktoryzacja tesów

Udostępniliśmy do pobrania artykuły z nowych serii publikowanych w programistamag.pl przez moich współpracowników:

• Michał Charmas rozpoczął serię Zaawansowane programowanie na platformie Android artykułem There is no app - do pobrania tutaj: http://bottega.com.pl/artykuly-i-prezentacje#android
• Rafał Jamróz rozpoczął serię Refaktoryzacja testów legacy w kierunku wykonywalnych specyfikacji artykułem Podstawowy refaktoring testów - do pobrania tutaj: http://bottega.com.pl/artykuly-i-prezentacje#testowanie

Zapraszamy do lektury:)

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.

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

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.