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.
Inżynieria oprogramowania w ujęciu systemowym.
Zintegrowane podejście do metodyk,
technologii (głównie Java EE), architektury i rozwoju ścieżki kariery programisty.
piątek, 27 lutego 2015
poniedziałek, 16 lutego 2015
Przykład problemów z ubiquitous language
Piękny przykład na problemy w komunikacji świata IT, medycyny i inżynierii przesyłu cieczy. Moim zdaniem prezentacja jest ciekawa sama w sobie merytorycznie, ale pokazuje też, że inne branże mają problemy tej samej klasy:)
Warto obejrzeć aby mieć świadomość jakie jeszcze siły działają na projekt oprócz wycieków pamięci;)
http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_own_heart
Warto obejrzeć aby mieć świadomość jakie jeszcze siły działają na projekt oprócz wycieków pamięci;)
http://www.ted.com/talks/tal_golesworthy_how_i_repaired_my_own_heart
Subskrybuj:
Posty (Atom)