Połączenie BDD z DDD

Community Behavior Driven Development zaczyna się reflektować, że metodyka daje bardzo płytkie rozumienie domeny.
W artykule  http://www.infoq.com/news/2015/02/bdd-ddd znajdziecie link do prezentacji https://skillsmatter.com/skillscasts/6240-taking-back-bdd która pokazuje jak i dlaczego integrować BDD i Domain Driven Design.

O ile zgadzam się co do idei, to prezentowana implementacja wydaje się być po prostu szkodliwa. Historyjka akceptacyjna operuje na obiektach domenowych, zamiast na wyższej warstwie, czyli serwisach aplikacyjnych lub CommandHandlerach.

Jaka jest konsekwencja? Historyjka powiela logikę wyższej warstwy. Nie tędy droga... Pomylono po prostu Domain Story z User Story i stąd taki kuriozalny efekt. Może gdyby prelegent napisał nieco kodu, to by uświadomił sobie błąd w rozumowaniu;)

O powierzchowności User Story mówiłem tutaj: https://www.youtube.com/watch?v=z0y3IPJDyp0


//======================
Podobne problemy napotkamy stosują Spec by Example. Nie chcę być źle zrozumiany, nie twierdzę, że BDD czy SBE są błędne, są po prostu niewystarczające dla nietrywialnych domen.

Inna obserwacja: czy ludzie biznesu na pewno potrafią dobrze operować przykładami? Ile przykładów można zmieścić w pamięci podręcznej mózgu? Może przykłady są dobre w początkowej fazie poznawania domeny a później wygodniej od nich abstrahować? Odpowiedź brzmi oczywiście: "to zależy". Ale zależy od czego? Od nawyków kognitywnych konkretnego człowieka. Niektórzy preferują abstrakt a inni konkret, jeszcze inni najpierw jedno, później drugie.

Więcej na ten temat można zacząć eksplorować np tutaj: http://en.wikipedia.org/wiki/Learning_styles#David_Kolb.27s_model

Modeling Whirlpool z DDD idealnie integruje wszystkie style uczenia (poznawanie domeny jest uczeniem się jej) z Cyklów Kolba.

Czego mama nigdy nie mówiła Ci na temat testowania automatycznego

Na YT opublikowano moją prezentację z zeszłorocznej konferencji JDD: https://www.youtube.com/watch?v=znRByMgnFSM

Czego możesz się z niej dowiedzieć:
- jeżeli testy używają Mocków "to wiedz, że coś się dzieje"
- jeżeli w typowym projekcie biznesowym dąży się do pokrycia 80% "to wiedz, że coś się dzieje"
- jeżeli testy akceptacyjne są napisane językiem kontrolek UI  "to wiedz, że coś się dzieje"
- jeżeli widzisz (anty) wzorzec Page Object "to wiedz, że coś się dzieje"
a poza tym testy end-to-end powinny mieć warstwy - jak wszystko:)

...oraz jak działają automatyczne skrzynie biegów w super-samochodach.


Materiały: http://prezi.com/cxslyh5sqo_z/czego-mama-nigdy-nie-mowia-ci-na-temat-testowania-automatycznego/

Materiały o BDD i Spec by Example z Warsjawa i JDD

Na prośbę uczestników podaję materiały, które były wykorzystane:
- podczas prezentacji Rafała Jamroza na JDD
- podczas warsztatów prowadzonych przeze mnie i Rafała na Warsjawa

Behavior Driven Development, czyli Agile 2.0

Zapraszamy na warsztaty z "wypiekania zaczynu" (DDD, BDD, CqRS)

W najbliższą sobotę (1 października) organizujemy w ramach lubelskiego JUGa otwarte warsztaty z zakresu:
- modelowania z wykorzystaniem Domain Driven Design
- procesu Behavior Driven Development (w tym wykorzystanie JBehave, Selenium i Agentów)
- architektury Command-query Responsibility Segregation

Warsztaty będą przeprowadzone na podstawie materiałów z otwartego i darmowego projektu DDD+CqRS Leaven.

Szczegóły wydarzenia na stronie JUGa.


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

Dla zainteresowanych z innych zakątków Polski informacja: planujemy tego typu inicjatywy podczas zbliżających się konferencji branżowych - szczegóły wkrótce.

Głuchy telefon

Głuchy telefon - intrygująca i dająca do myślenia zabawa z dzieciństwa, gdzie nawet bardzo prosta "informacja" może zostać zniekształcona po przejściu przez łańcuch "przekaźników".

Kultowy obrazek z huśtawką (który wszyscy znamy) obrazuje co dzieje się z informacją nieco bardziej wyrafinowaną (np. na temat wymagań) w procesie produkcji softu.

Jak temu zapobiec?
Racjonalnym rozwiązaniem jest Ubiquitous Language - kluczowa technika w Domain Driven Design polegająca na operowaniu wspólnym słownictwem domenowym na każdym poziomie abstrakcji: począwszy od eksperta biznesowego po kod źródłowy (sic!) w warstwie logiki aplikacji i logiki domenowej. W logice domenowej oczywiście obowiązuje ścisła "etykieta" - korzystanie z dobrze zdefiniowanych Building Blocks.

W tym miejscu dochodzimy do sedna posta.
Zachęcam do zapoznania się z prezentacją mego guru - Erica Evansa: "Sustainable Design for Agile Teams" podczas, której mamy próbkę sesji analitycznej pomiędzy programistą a ekspertem domenowym. Zwróćcie uwagę na dobrze zdefiniowany, wspólny język jakim posługują się obie strony oraz w jaki sposób "odkrywają" nowe byty.

Oczywiście taki proces nie jest tani oraz wymaga cennego zasobu: eksperta domenowego:/

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

Prezentacja porusza również inny, arcyważny aspekt: niezrozumienie projektowania domeny w naiwnym podejściu do Agile. Kiedy skupiamy się na pojedynczym wymaganiu lub na pojedynczej iteracji, wówczas zwykle mamy do czynienia ze specjalnym przypadkiem procesu biznesowego w jakiejś domenie. Gubimy "biger pikczer" i z czasem całość sprowadza się do radosnego (później smutnego) "hakowania" kodu opisującego jakieś specjalne przypadki - zaszłości. I nie ma co się oszukiwać - nikt nie jest skory do refaktoringu modelu domenowego, który jest już napełniony danymi w bazie:)