Cytaty #2

"We have tried to demonstrate by these examples that it is almost always incorrect to begin decomposition of a system into modules on the basis of flowchart.

We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others."

David L Parns
"On the Criteria to Be Used in Decomposing Systems into Modules"
za: http://www.infoq.com/presentations/Architecture-Uncertainty - prezentacja jednego z moich ulubionych "filozofów oprogramowania", który dodaje później:
"Projektujemy wokół tego czego nie wiemy, ukrywamy niewiedzę, aby niewiedza nie była problemem"

Video z Confitury

Właśnie się zorientowałem, że od jakiegoś czasu dostępna jest moja prezentacja z tegorocznej Confitury: Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się podczas 6 lat praktykowania i nauczania DDD).

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.

Wrocław 28 i 29 października

Szybki ogłoszenie:

Zapraszam wszystkich chętnych na otwarte spotkania w najbliższym tygodniu we Wrocławiu

• 28 października: Wrocław JUG - prezentacja na temat testowania automatycznego (dla programistów): https://groups.google.com/forum/#!topic/wroclaw-jug/tR-xgr0X-Wo
• 29 października: DDD-WRO - spotkanie poświęcone technikom modelowania: http://www.meetup.com/DDD-WRO/events/146833852/

Przyczyna czy skutek?

Po 6 latach praktykowania DDD, prowadzenia i uczestniczenia w licznych warsztatach i szkoleniach chyba wreszcie zrozumiałem o co chodzi w całym tym Domain Driven Design...

Wszystko dzięki trafiającemu (jak zwykle) w sedno postowi Jarka Żelińskiego: Czy aby na pewno zarządzamy procesami biznesowymi?

Wstęp

Patrząc na warstwową architekturę systemu opartego na DDD mamy:

UI
----------------------
Application (API)
----------------------
Domain Model
----------------------
Infrastructure

(możemy użyć również popularnej ostatnio metafory Heksagonu - ale nie wpływa to na wywód)

W warstwach UI+APPlication możemy możemy mieć zamodelowany proces biznesowy. Ew. szczególnym klientem do API (również obok np apliakcji webowej) może być silnik procesów biznesowych.
W warstwie Domain rezyduje model bazowych reguł biznesu ("fizyki" biznesu) zamodelowany przy pomocy Building Blocks DDD, które chronią niezmienniki. Więcej o BB: DDD krok po kroku.

Problem: Od czego zacząć modelowanie?

Od procesu czy od domeny? Innymi słowy: od ogółu czy od szczegółu?
W Domain Driven Design zaczynamy (niespodzianka) od modelowania warstwy Domain. API i proces to rzecz wtórna.

To zależy...

Jak w każdym nietrywialnym przypadku, odpowiedź  na pytanie zależy od kontekstu.

W przytoczonym na wstępie artykule znajdziemy olśniewającą (przynajmniej dla mnie) wskazówkę:

• czy proces biznesowy wyłania się z reguł niższego rzędu - innymi słowy model domenowy nakłada ograniczania, które wyznaczają "trajektorię" procesu, który lawiruje pomiędzy nimi niczym strumień rzeki w jej korycie (posługując się metaforą Jarka)
• czy może to raczej proces narzuca kształt modelowi domenowemu?

W DDD podchodzimy do modelu w ten pierwszy sposób - zaczynamy od domeny, czyli fundamentalnych reguł i ograniczeń, w które wpasowuje się proces.

Trudne pytanie

Po czym poznać z którą sytuacją masz do czynienia? Najpewniej w dużym systemie mamy obie...

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

To w sumie wydaje się oczywiste, ale sztuką jest tak ubrać myśl w słowa, aby (np przez porównanie dwóch podejść) ująć ideę w jednoznaczny sposób.

Podaj dalej

Tytułem posta chciałem nawiązać do znakomitego filmu Pay It Forward opowiadające historię chłopca, który w ramach zadania domowego musiał pomóc trzem osobom, uruchamiając w ten sposób łańcuszek szczęścia...


33rd Degree 4 charity
13 października odbędzie się w Krakowie konferencja 33rd Degree 4 charity. Z opisu organizatora: "Caly dochod z rejestracji zostanie przeznaczony na cele charytatywne. W tym http://www.szlachetnapaczka.pl/ i http://www.mammarzenie.org/. W zaleznosci od ilosci funduszy jakie uda nam sie zebrac byc moze uda sie wspomoc takze inne fundacje, np. http://www.wikipedia.org/. [...] Podczas rejestracji sam wybierasz jaka kwota chcialbys wspomoc potrzebujacych. Moze to byc 50, 100, 150 lub 200 zl, lub wiecej jesli chcesz".

(Nie do końca) darmowe szkolenie Scrum

4 października kolega Wiktor organizuje szkolenie Scrum na zasadzie Pay it Forward: "Jedyne czego oczekujemy od Was to, to że w zamian za 8 godzin udziału w szkoleniu poświęcicie 8 godzin swojego czasu dla społeczności". Link do szczegółów: http://blog.testowka.pl/2013/09/17/nie-do-konca-darmowe-szkolenie-scrum/

Piwo, kiełbasa i testowanie automatyczne

Starożytni celebrowali wino, kobiety i śpiew.
Cywilizacja poszła do przodu i współcześni dżaważe celebrują piwo, kiełbasę i testowanie automatyczne.

W imieniu organizatorów i swoim zapraszam na jPiknik: http://jpiknik.pl/ podczas którego przedstawię prezentację: Czego mama nigdy nie mówiła Ci na temat testowania automatycznego (prezi) oraz wraz z Rafałem poprowadzimy warsztat Jak wyprowadzić słabe i smutne testy na prostą oparty na doświadczeniach coachingowych Rafała.

14 września w Temat Rzeka na Plaży przy Moście Poniatowskiego w Warszawie, wstęp wolny.

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

Dla zainteresowanych warsztatem: Rafał poprowadzi reedycję na tegorocznej Warsjawie.

Wzorce analityczne modeli biznesowych

Zapraszam do lektury kolejnego artykułu z serii Receptury projektowe - niezbędnik początkującego architekta pod tytułem Wzorce analityczne modeli biznesowych na przykładzie Party – odkrywanie krok po kroku kolejnych rozwiązań.

Tym razem debiut nowej autorki w tematyce z pogranicza analizy systemowej, architektury aplikacyjnej i modelowania.

Streszczenie: Techniki takie jak Domain Driven Design służą do odkrywania wiedzy na temat nieznanych domen biznesowych. Jednak często pracujemy nad problemem, który został już dobrze przemyślany i opracowany kilka dekad temu. W niniejszym artykule przedstawimy
koncepcję Wzorców analitycznych – czyli wzorców adresujących rozwiązania na poziomie
analizy systemowej. Koncepcja wzorców analitycznych będzie ilustrowana na przykładzie
kilku wybranych, w tym najbardziej popularnym z nich: Party – będą one również alternatywą dla typowych naiwnych książkowych modeli struktur organizacyjnych.

Artykuł do pobrania tutaj: http://bottega.com.pl/artykuly-i-prezentacje#receptury

Kontrreformacja:)

Programming Motherfucker Manifesto

A miało być tak pięknie...

W jaki sposób zbudować formę i zaplanować treść prezentacji, która: jest prowokacyjna ale skłania do refleksji, jest arcy-śmieszna oraz obrazoburcza wobec gigantów branży i dogmatów a przy okazji jest rodzajem rozliczenia tego czego dokonaliśmy?

Na przykład tak:




Bret Victor - The Future of Programming from Bret Victor on Vimeo.

Oglądaj w pełnym skupieniu, bo każdy detal w formie, każdy szczegół w treści wyzwala wewnętrzny chichot (oczywiście o ile jesteś geekiem:).

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

btw: gdzie można kupić takie ochraniacze na długopisy do kieszeni koszuli?

This is where the one who knows meets the one who doesn't care

"This is where the one who knows meets the one who doesn't care" - wers z utworu Chrisa Rea; płyty Chrisa towarzyszą mi często w samochodzie gdy godzinami przemierzam trasy prowadzące do kolejnego hotelu...

Dziś będzie o próbach komunikacji i wyzwaniach jakie są z nią związane oraz (niestety) o parszywych manipulacjach. Jako studium przypadku posłuży nam coś w stylu konwersacji dwóch ekspertów, zasłużonych weteranów w naszej branży: Jim Coplien i Bob Martin debatują na temat słuszności TDD.



Zacznę od zaznaczenia, że nie zajmuję stanowiska wobec treści. Nie będę stawał po żadnej stronie w tej dyskusji, skupię się na formie i wybranych wzorcach i antywzorcach jakie możemy obserwować podczas "konwersacji" w naszej branży. Zresztą... jeżeli programujesz już od kilka lat, to zapewne wiesz, że każda nietrywialna technika działa jedynie w kontekście problemu a poza nim może być wręcz szkodliwa.

Źródło autorytetu
Jeden z interlokutorów powołuje się na autorytet własnej osoby. Cytuje sam siebie. Opiera argumenty na definicjach, które sam wymyśla.

Drugi zaś, podpiera się autorytetem zewnętrznym powołując się na cytaty innych osób. O ile nie jest to tak śmieszne jak poprzednia strategia, to czy przez to staje się bardziej wiarygodne?

Generalnie mamy tutaj zderzenie dwóch strategi kognitywnych: "co by powiedzieli inni?" vs "chrzanić innych, ja mówię jak jest".

Piętnowanie
Któż z nas nie chciałby być uważany za profesjonalistę (w polskim rozumieniu tego słowa, a nie angielskim, gdzie jest to ktoś zarabia na danej działalności)?

Jak pewnie zauważyliście, jeden z rozmówców stwierdza na wstępie, że ten, kto nie praktykuje pewnej techniki w swej pracy nie jest profesjonalistą. Techniki, która jest rdzeniem jego komercyjnych produktów:) Nie stoi za tym stwierdzeniem żadna sensowna argumentacja ani odniesienia do badań, po prostu własne "widzimisię" - wynikające ze źródła autorytetu.

Drugi z rozmówców mógłby w tym momencie zastosować tani chwyt zdając pytanie: "a co z tymi setkami tysięcy ludzi, którzy nieszczęśliwie urodzili się przed popularyzacją metodyki, czy byli szmaciarzami?" Zamiast tego powołuje się na badania, które wykazują szkodliwość metodyki (rozumianą jako zwiększenie ilości błędów) - ale pamiętajmy, że badania przeprowadzono w specyficznym kontekście.

Mowa ciała
Jaskrawe niedopasowanie rozmówców możemy zaobserwować na poziomie niewerbalnym. Jeden z nich często gestykuluje do swego centrum (w tym wypadku w kierunku splotu słonecznego). Widać silną inteligencję kinestetyczną, tok rozumowania wspierany wyobrażeniami ruchowymi.

Drugi zaś większość czasu spędza "w głowie". Zamiast dyskusji mamy więc "wymianę sygnałów" pomiędzy intuicją jednego z rozmówców a konstruktami złożonymi z abstraktów drugiego z nich.

Gdy następnym razem będziesz świadkiem jałowej dyskusji podczas spotkania projektowego zwróć uwagę na taki "szczegół" jak dopasowanie postaw rozmówców. Spotkanie będzie generalnie pozbawione sensu, ponieważ obie strony używają zupełnie innych reprezentacji mentalnych, innymi słowy mają w głowie inne modele, oparte na innych założeniach. Na poziomie werbalnym niby wszystko jest ok, ale dyskusja jakoś nie doprowadzi do konkluzji i wspólnego działania.

Pomocyyyy...
Niemowlęta mają w repertuarze swoich zachowań specjalny ruch: odruch Moro. Pomaga to im poczuć się lepiej. U dorosłych ludzi zredukowana wersja odruchu (założenie rąk ponad głowę) pojawia się nieświadomie, gdy chcieliby aby mama przyszła i zabrała ich już z niewygodnej sytuacji. Ew. dodaje nieco otuchy i pozwala zabrać myśli aby przejść do kontrataku z wykorzystaniem klasycznych technik erystycznych.

Tak, tak
Podobno ludzie kiwają głową gdy się zgadzają - ale z samym sobą (wewnętrznie w "myślach"). Tak więc jeżeli widzisz uśmieszek w kąciku ust i kiwanie głową, to masz pewność, że interlokutor przestał właśnie słuchać i testuje pławienie się w rozkoszy riposty jaką przygotował do poprzedniego zdania. Możesz skończyć wydawanie dźwięków, trafiają na /dev/null.

Dreyfus.
Model rozwoju kompetencji Braci Dreyfus jest ostatnimi czasy popularny w naszej branży. Jeżeli się z nim nie spotkałeś/spotkałaś, to zachęcam do zapoznania się z wstępem do wstępu.

Generalnie widać różnicę w targetowaniu przekazu: jeden z rozmówców celuje w odbiorców będących na I i II poziomie Dreyfus, którzy oczekują prostych i bezkontekstowych reguł postępowania. Drugi może być odebrany ze zrozumieniem tylko na kolejnych poziomach.

Nadużywanie słowa "architektura"
Mam takie przemyślenie, że najczęściej używane słowa w naszej branży: komponent, moduł i architektura są rozumiane "intuicyjnie". Czyli nikt nie wie, co to tak na prawdę jest. Szczególnie słowo "architektura" doklejane jest do tytułów książek i prezentacji służąc zwykle do zdobywania ekstra punktów reputacji;)

Obaj panowie zdają się poruszać temat Object Oriented Design, tam gdzie pada słowo architektura. Oczywiście mamy różne skale architektury (aplikacyjna, systemowa, wdrożeniowa, skalowania, bezpieczeństwa), ale generalnie rozumiem to słowo jako "design of design". Czyli w przypadku architektury aplikacyjnej będą to struktury ponad OOD (np, warstwy, heksagony, pipes&filters itd)


Na zakończenie kolejny akcent muzyczny (jeżeli nie przepadasz za starożytną muzyką, to wystarczy intro)




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

A tutaj Paweł Badeński zwraca uwagę na inne ciekawe błędy oraz wyjaśnia dlaczego nasza branża nigdy nie będzie postrzegana poważnie przez tak zwane prawdziwe dziedziny nauki:)

Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA

Czy wiesz, że:

• Lazy Loading nie ma sensu
• Mapowanie @OneToMany z wykorzystaniem tabeli linkującej (domyślne zachowanie hibernate) nie ma sensu
• Blokowanie Optymistyczne oparte jedynie na @Version nie ma sensu

...jeżeli stosujesz zasady Object Orinted i JPA (lub inny maper relacyjno-obiektowy).


Jeżeli powyższe tezy targnęły Twoimi emocjami, to zapraszam do lektury najnowszego artykułu: Mapowanie relacyjno-obiektowe prawdziwych obiektów – rzecz o DDD i JPA (do pobranie całkowicie free), który ukazał się w najnowszym numerze programistamag.pl (wakacyjny numer o podwójnej objętości dostępny w Empikach lub w formie elektrycznej).

Zapraszam do śledzenia całej serii Laboratorium Bottega - Receptury projektowe – niezbędnik początkującego architekta.

3 zasady optymalizacji

1. Nie optymalizuj - jeżeli na prawdę tego nie potrzebujesz - być może to "tylko" twoje ego chce się pobawić pozostając w strefie komfortu; spójrz na parking za oknem i policz ile samochodów tam stojących było projektowanych z myślą szybkości (chyba, że pracujesz w centrum Londynu:)
2. Nie optymalizuj jeżeli nie rozumiesz co robisz - być może dotkniesz warstw, gdzie nie sięgają Twoje kompetencje - i być może cały Twój wysiłek zostanie zniweczony na poziomie pakietów i ramek TCP/IP lub będzie pomijalny dzięki optymalizacjom wirtualnej maszyny
3. Nie optymalizuj jeżeli nie mierzysz wydajności przed i po - być może intuicja, która świetnie działa na sawannie, nie działa w świecie krzemu - i być może wysłanie kilku zapytań do bazy danych, obróbka wyników w pamięci serwera aplikacji jest lepszym pomysłem niż jedno zapytanie z 30 joinami:P

btw: pamiętaj, że wirtualna maszyna Javy "wie" o optymalizacji więcej niż znakomita większość programistów C - zwykle wystarczy się nie wydurniać, a JVM zajmie się resztą...

Twój mózg Cię oszukuje (gdy uczysz się nowego języka)

Dziś chciałbym polecić prezentację, którą powinien obejrzeć każdy programista: Don’t Trust Your Brain.
Treść przyda się szczególnie tym z Was, których zmuszono do nauki nowego języka programowania (jeżeli uczysz się z własnej woli, to za pewne idzie znacznie łatwiej:)

W lekki, zabawny i okraszony wiedzą za zakresu psychologii sposób dowiecie się, że składnia to przysłowiowy pikuś; kluczowe są: kultura, narzędzia, wzorce i idiomy.

//================================================
Zawsze przerażali mnie programiści klasy King Bruce Lee Karate Mistrz, którzy twierdzą, że "każdego języka mógłbym nauczyć się w tydzień (ale mi się nie chce)". Później widzimy potworki napisane np. w Javie w C albo w C# w Cobolu...

Open/closed principle - zastosowanie na poziomie architektury aplikacji oraz metafory wizualne

"Kod powinien być otwarty na rozbudowę jak kwiat lotosu o świcie i zamknięty na zmiany jak kwiat lotosu o zmierzchu" - jako początkujący projektant natknąłem się kiedyś w jednej z książek na takie "Buddyjskie" wyjaśnienie Open/Closed Principle - jednej z zasad SOLID.

Jednak jak w praktyce zastosować tą zasadę? Czy aplikuje się ona jedynie na poziomie Object Oriented Design czy również na poziomie architektury aplikacyjnej?

W najnowszym artykule "Zarządzenie złożonością przez trójpodział logiki – Open/closed principle w praktyce" opublikowanym na łamach programistamag.pl przedstawiłem swoje przemyślenia na temat OCP, w których integruję:

• ODD, 
• podstawy podejścia funkcyjnego, 
• Building Blocks wchodzące w skład Domain Driven Design,
• architekturę na poziomie aplikacyjnym.

W artykule chciałbym zaproponować Wam swego rodzaju "framework mentalny", który pozwala zmierzyć się ze złożonymi problemami dzieląc logikę na 3 kategorie:

• stabilną - której kod relatywnie rzadko podlega zmianom
• domknięcia logiki - które nie polegają zmianom a rozbudowie
• wybór domknięć - zmiany enkapsulowane w fabrykach (zgodnie z regułą Uncle Boba: "instrukcje switch są dozwolone jedynie w czeluściach fabryk":)

Zatem jest to meta-model, który pozwala na tworzenie modeli problemów zgodnych z OCP. W artykule znajdziecie również propozycję 3 rodzajów wizualizacji graficznej OCP: jedno, dwu i trójwymiarową - w zależności od preferencji kognitywnych...

Artykuł do pobrania (jak zwykle całkowicie za darmo) tutaj: http://bottega.com.pl/artykuly-i-prezentacje

C4 - Zwinne podejście do odkrywania i dokumentowania architektury

W jaki sposób dokumentować architekturę systemu - z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną?

Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział  gdzie 'włożyć ręce'".

Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".


/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).

**************************/

Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.

Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).


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

Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.

Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4:  mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).

Materiały z konferencji 33rd Degree

Oto obiecane materiały:

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego - problemy, strategie, taktyki, techniki i narzędzia






Model jest wszystkim czego potrzebujesz (w aplikacjach biznesowych) - czyli czego nauczyłem się w ciągu 6 lat stosowania i nauczania DDD






Dodatkowo dla osób, które pytały o inne prezentacje:

Architektura Ports & Adapters
Wstęp do DDD: Domain Driven Design - A place for everything and everything in its place
Architektura CqRS: Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw

Projekt referencyjny: DDD & CqRS Sample Leaven


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

Jak zwykle feedback odnośnie prezentacji mile widziany - może być na prv.

Mock czy Stub? Command-query Separation prawdę ci powie.

Testując jednostkowo sieć powiązanych obiektów, dążymy do ich testowania w separacji. Separację osiągamy dzięki stosowaniu różnego rodzaju „dublerów”.

Często bez zastanowienia stosujemy dublery typu Mock. Mocki są relatywnie pracochłonną techniką, która nie zawsze jest uzasadniona - czasem wystarczający jest Stub (Fowler o różnicy pomiędzy Mock a Stub: Mocks Aren't Stubs).


W najnowszym wydaniu programistamag.pl opublikowałem artykuł zatytułowany "Mock czy Stub? Command-query Separa-tion prawdę ci powie." przedstawiający pragmatyczną „reguła kciuka” oparta o paradygmat Command-query Separation, która daje prostą odpowiedź co do typu dublera, jakiego potrzebujemy w teście jednostkowym.

Artykuł tradycyjnie do pobranie (całkowicie darmowo) tutaj: http://www.bottega.com.pl/artykuly-i-prezentacje.

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

Dla niecierpliwych esencja reguły:

• metody typu query -> użyj Stub
• metody typu command -> użyj Mock

Cztery smaki odwracania (i utraty) kontroli: Dependency Injection, Events, Aspect Oriented Programming, Framework

W styczniowym wydaniu programistamag.pl ukazał się kolejny mój artykuł pt.: Cztery smaki odwracania (i utraty) kontroli: Dependency Injection, Events, Aspect Oriented Programming, Framework.

Tekst jest syntezą wieloletnich doświadczeń i przemyśleń na temat Inverion of Control. Kolejne techniki coraz to silniejszego odwracania kontroli (powiązanego z jej utratą) zostały opisane wg struktury:

• problem - jaki problem chcemy rozwiązać, po co w ogóle odwracamy kontrolę w ten sposób
• idea - ogólna idea zawarta w jednym zdaniu, która pozwoli uchwycić esencję
• motywacja - kiedy mogę zacząć zastanawiać się nad wprowadzeniem tej techniki
• zastosowanie - jakie są dodatkowe zastosowania (poza rozwiązaniem problemu) ew benefity uboczne/wyższego rzędu
• techniki - jakimi technikami implementacyjnymi mogę osiągnąć odwrócenie
• kiedy nie stosować - najważniejsze: gdzie jest granica stosowalności, na co uważać aby nie skończyć z syndromem "nakładania gaci przez głowę"

Artykuł do pobrania (jak zwykle całkowicie za darmo oraz bez rejestracji:) tutaj: http://bottega.com.pl/artykuly-i-prezentacje#receptury

Artykuł jest jednocześnie pierwszym z nowej serii: Receptury projektowe – niezbędnik początkującego architekta.

Intencją serii „Receptury projektowe” jest dostarczenie usystematyzowanej wiedzy bazowej początkującym projektantom i architektom. Przez projektanta lub architekta rozumiem tutaj rolę pełnioną w projekcie. Rolę taką może grać np. starszy programista lub lider techniczny, gdyż bycie architektem to raczej stan umysłu niż formalne stanowisko w organizacji.

Wychodzę z założenia, że jedną z najważniejszych cech projektanta/architekta jest umiejętność klasyfikowania problemów oraz dobieranie klasy rozwiązania do klasy problemu. Dlatego artykuły będą skupiały się na rzetelnej wiedzy bazowej i sprawdzonych recepturach pozwalających na radzenia sobie z wyzwaniami niezależnymi od konkretnej technologii, wraz z pełną świadomością konsekwencji płynących z podejmowanych decyzji projektowych.

Seria z kolei jest początkiem nowego działu w programistamag.pl: Laboratorium Bottega. W dziale tym będziemy publikować podejścia, rozwiązania i techniki, które stosujemy na co dzień w praktyce projektowej, podczas warsztatów i szkoleń oraz coachingu.

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

Artykuł powstał niejako "na zamówienie" jednego z czytelników bloga. Temat był po prostu zbyt obszerny jak na posta.

Jeżeli ktoś chciałby "zamówić" jak temat to proszę pisać śmiało w komentarzach lub na priv: slawomir.sobotka w domenie bottega.com.pl

Nocna zmiana

Mój ojciec pracował niegdyś w trybie zmianowym (zmiana poranna, popołudniowa i nocna). Wynikało to wówczas z utrzymania ciągłości produkcji w fabryce i realizacji planów gospodarki sterowanej centralnie.

Bez obaw - nie zamierzam pisać o polityce i centralnym sterowaniu gospodarką:)

Wielu programistów pracuje po nocach - niektórzy sobie to chwalą, inni przeklinają nie mogąc wyrwać się z tego programu dobowego. Mnie również się to zdarza.

Do tej pory myślałem, że są tego 3 (mniej lub bardziej) powszechnie znane przyczyny (które zapewne się nakładają na siebie):

1. doświetlenie szyszynki przez matryce naszych komputerów, co w efekcie rozregulowuje wydzielanie melatoniny
2. brak energii o poranku (a kumulacja wieczorem) spowodowany rozregulowaniem wydzielania kortyzolu - wynik diety opartej na węglowodanach
3. po prostu rozproszenie przez to co dzieje się dookoła nas (to zależy jeszcze od wyczulenia percepcji któregoś ze zmysłów)

Dziś w mailingu z linkedin dostałem linka do ciekawego artykułu: Why Programmers Work At Night, w którym to autor integruje całość:

• odnosząc się do pierwszeej przyczyny
• odnosząc się do przyczyny trzeciej: nazywa dwa rodzaje skupienia: ludzi zarządzających vs ludzi wytwarzających (coś wartościowego;) Ludzi zarządzający dzielą czas na odcinki, ludzie tworzący kreatywne połączenia muszą "załadować sobie kontekst" - ciekawe zwerbalizowanie tego co każdy jakoś tam intuicyjnie czuje
• podaje kolejną hipotezę: zmęczenia mózgu, która gdy się nad nią zastanowić ma "intuicyjny sens"

Kolejna hipoteza zakłada, że hiper-aktywność mózgu, która nie pozwala się nam skupić na jednej rzeczy i prowokuje do "skoków w bok"  (powszechnie znany problem) znika jeżeli mózg jest dostatecznie zmęczony. Daje to możliwość "załadowania kontekstu" i wykonania na nim operacji.

Zatem wieczorem, gdy jesteśmy już zmęczeni na tyle, że nie możemy się rozpraszać i możemy skupić się na jednym wątku następuje czas, gdy można zrobić coś sensownego:)

Szkoda tylko, że w artykule nie ma odnośników do badań:P

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

O różnicach w wewnętrznym modelowaniu czasu pisałem dawno temu.

A jak to jest w Waszym przypadku?

100 mandaysów za dodanie jednego checkboxa?!?

Standardowa scenka: spotkanie tak zwanego "biznesu" z tak zwanym "IT"; dyskusja nad "małą kosmetyczną zmianą" polegającą na "dodaniu jedynie małego checkboksa".

Na minach "IT" najpierw pojawia się grymas namysłu, a następnie ekspresja (nie mikro-ekspresja) zagłady i katastrofy. W wyobraźni ujrzeli trzęsienie ziemi, która kruszy katedrę, którą budują od x miesięcy/iteracji/cokolwiek. "IT" przełyka ślinę i odpowiada: "zajmie nam to 100 mandaysów".

Mina "biznesu":

Dalszy rozwój scenariusza może przebiegać różnie w zależności o relacji - czy mamy negocjacje klient-dostawca, dział biznesowy-dział it, itd.

Typową dziecinną techniką jest zaniżanie o połowę, ale IT już wie, że "oni zawsze zaniżają", więc defaultowo  zawyża, jednak biznes, wie, że "oni defaultowo zawyżają", więc zaniża 4-krotnie, itd... wszyscy traktują się nawzajem jak by druga strona była opóźniona.

W każdym jednak przypadku "IT" jest na przegranej pozycji. Podczas gdy "my" doskonalimy się we frameworkach, wzorcach i architekturach, "oni" zdobywają siódmy czarny pas w NLP i technikach manipulacji wszystkim czym da się manipulować...

Skąd bierze się takie niezrozumienie powagi zmiany?

Najprawdopodobniej obie strony mają w swoich umysłach inne modele mentalne problemu oraz jego złożoności.

Bywalcy konferencji oraz czytelnicy książek przyprawionych nutką Agile próbują posiłkować się metaforą "Długu technicznego", który został kiedyś zaciągnięty i oto nadeszła chwila, kiedy trzeba go spłacić. "Ale jaki dług, przecież działa!" - możemy usłyszeć w odpowiedzi.

Gdyby istniał wspólny model domeny problemu, wówczas każdy uczestnik projektu "czułby" intuicyjnie powagę zmiany. Ew. naiwne uproszczenia dokonywane z wielu (zwykle racjonalnych) powodów, mogłyby być dokonywane ze świadomością konsekwencji. Uświadomiony dług techniczny.

Dla przykładu: powyżej widzimy model budynku wydrukowany przez drukarkę 3D. Nawet osoba nietechniczna intuicyjnie poczuje, że "postawienie o tutaj (wskazuje palcem na dach) lądowiska dla helikoptera" będzie "nieco" kosztowne. Trzeba przecież znacznie rozbudować konstrukcję nośną albo jeżeli chcemy ją zachować wymienić słupy na tworzywo wykradzione z NASA;)

Spróbujmy osiągnąć taki poziom świadomości gdyby obie strony siadły do: a) rysunków technicznych, b) dokumentów wizji, przeczuć i życzeń zwanych czasem dumnie artefaktami analitycznymi.

Ten przydługi wstęp miał być zachętą do zapoznania się z ostatnim z publikowanej w programistamag.pl serii "DDD krok po kroku": Modeling Whirlpool – iteracyjny proces modelowania (dostęp jest całkowicie darmowy).

Modeling Whirpool jest zwinnym procesem tworzenia wspólnego modelu, który jest zrozumiały również dla Eksperta Domenowego oraz implementowalny 1:1 w kodzie źródłowym - żadnych poziomów abstrakcji, które tworzą luki semantyczne.

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

W styczniowym numerze rozpoczynam nową serię: "Niezbędnik początkującego Architekta", wktórej znajdziecie systematyzację (mam nadzieję) wiedzy bazowej oraz kilka sprawdzonych receptur.

Zainteresowanych DDD i Modeling Whirlpool zapraszam na konferencję 33rd Degree - prezentacja i warsztaty.