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/embed/z0y3IPJDyp0
//======================
Podobne problemy napotkamy stosują Spec by Example. Nie chcę być źle zrozumiany, nie twierdzę, iż 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.
