wtorek, 1 października 2013

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.

wtorek, 24 września 2013

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/


środa, 11 września 2013

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.

środa, 28 sierpnia 2013

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

niedziela, 11 sierpnia 2013

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?

środa, 7 sierpnia 2013

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:)