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.
4 komentarze:
"Historyjka powiela logikę wyższej warstwy." Mógłbyś bardziej rozjaśnić ?
"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ć?"
Tutaj myślę warto pokazać różnicę pomiędzy acceptance criteria a scenario (bo chyba to miałeś na myśli pisząc o tym czy przykłady są dobre). W dużym skrócie pierwszy jest regułą biznesową - pełną specyfikacją zachowania bez konkretnego przykładu. Scenariusz jest zaś konkretnym przykładem tego wymagania.
Według Liz K. i mnie również - rozmowa poprzez przykłady to kluczowy aspekt BDD bo w ten sposób jasno jesteśmy w stanie potwierdzić to czy stakeholders developerzy testerzy wspólnie rozumieją temat i w ten sposób najłatwiej możemy poddać naszą "niewiedzę" pod lupę. Łatwiej także chyba rozwijać konwersację i zadawać kolejne pytania operując na przykładach niż ogółach, które potem mogą być po jakimś czasie nie zrozumiałe.
Odnośnie pierwszego pytania:
Zacznijmy od ustalenia kontekstu: story może być formułowana na różnych poziomach. w sensie: ludzie robią to na różnych poziomach - np na tym na jakim jest im łatwo (mają wiedzę) a nie koniecznie na takim na jakim ma to wartość.
Chcąc integrować BDD z DDD (i odnosząc się do przykładu z linka) będziemy formułować na poziomie modelu domenowego.
Powstanie coś typu:
krok1
krok2
krok3
krok4
Ale
w DDD mamy monad modelem domenowym jeszcze model procesu w warstwie serwisów aplikacyjnych.
I powiedzmy, że z wymagań wyniknie taki podział:
serwis1{
krok1
krok2
}
serwis2{
krok3
krok4
}
I tutaj pojawia się pewien zgrzyt... z jednej strony mamy logikę z historyjkach (technicznie chcielibyśmy je odpalać jako testy - scenariusze akceptacyjne)
ale mamy ją też w serwisach.
Zmiana flow pociąga za sobą zmianę w serwisie i w scenariuszu akceptacyjnym.
Ale problem jest zupełnie inny - koncepcyjny! Dlaczego nasze scenariusze akceptacyjne są zbudowane na warstwie domeny a nie aplikacji?
Wydaje mi się, że to zostało pomieszane i w ogóle przeoczone w komentowanym przeze mnie artykule.
Co do drugiego pytania: story vs scenario. Faktycznie trzeba by tutaj znowu zacząć od zdefiniowania pojęć. Polskie "przykład" można zamapować na jedno lub drugie, zależy w jakiej formie są one sformułowane.
Mi chodziło wciąż o story. Jeżeli story jest sformułowane tak jak piszesz, na poziomie reguł biznesowych to ok.
Ale często wygląda to jak pewien szczególny scenariusz - przejście po regułach. Ale od razu powiem, że nie w sensie przykładu scenario z wartościami.
Spróbuję wyjaśnić na przykładzie:
mamy 3 reguły i czasem przepływ będzie r1, r3, a czasem r1, r2.
Wydaje mi się, że problem autora tekstu wciąż polega na (sprowadzając go do reprezentacji technicznej) nierozróżnianiu 2 warstw logiki: domenowej (reguły biznesu) i aplikacyjnej (reguły procesu, aplikacji). W dużych systemach tych warstw logiki może być nawet więcej.
Odnośnie Liz K. to nie wiem na jakich badaniach się opiera;P ale fakty są takie, że część ludzi będzie preferować przykłady a część ogóły i aby nie było jeszcze tak łatwo: będzie im się to dynamicznie zmieniać w zależności od postępu w zrozumieniu domeny. Są to po prostu osobnicze cechy - nazwijmy je nawyki kognitywne. Tak więc jak zwykle: empatia i zwinne dostosowanie się do sytuacji ponad mechanikę metodyki jaka sprawdziła się gdzieś, kiedyś, komuś w jakimś szczególnym kontekście po czym ją skodyfikował i zaczął sprzedawać;)
Masz rację wiele zależy od osób ich cech co przekłada się w różny sposób na łatwości w uczeniu/pojmowaniu domeny poprzez ogóły lub przykłady. Sam osobiście zauważyłem, że większość osób raczej wychodzi od ogólnych założeń bo jest łatwiej niż od jakiś konkretnych przykładów.
Jednak najważniejsze jest wspólne zrozumienie problemu biznesowego poprzez cały team. Stąd też osobiście działam tak gdy są jakieś reguły biznesowe i są one na tyle klarowane że jesteśmy w prosty sposób opisać je w postaci scenariuszy to nie ma sensu dalszego ich omawiana bo wszyscy rozumieją problem i jego wymaganie.
Gdy przychodzi do automatyzacji tego wymagania - wtedy daną regułę opisuję się w postaci kilku prostych scenariuszy (które docelowo są już opisywane przez osoby automatyzujące czyli developerów)
Gdy jednak dana reguła jest już bardziej skomplikowana to wspólnie omawiamy ją dzieląc ją na konkretne przykłady starając się odkryć jakieś edge casy itp..
Pytanie czy w miarę podobnie postępujesz czy masz jakiś innych schemat działania :) ?
---
Wracając do tego co słusznie zauważyłeś (tak teraz na to patrzę) i meritum posta to faktycznie automatyzacja scenariuszy akceptacyjnych z wykorzystaniem bezpośrednio logiki domenowej nie ma zbytnio sensu. Sama procedura może posłużyć do zamodelowania modelu jednak już całość powinna operować na serwisach aplikacyjnych - command handlerach (które defacto odwołują się do domeny i dla mnie przedstawiają jej API). Także serwisy aplikacyjne powinny być bezpośrednio użyte w kontekstach scenariuszy (tak jak to naszkicowałeś w przykładzie serwis1 serwis2) a nie obiekty domenowe (krok1 krok2 ...)
o to, to, właśnie!
Co do metodyki postępowania to parę razy fajnie sprowadziło się podejście ze Spec by Example.
Ale trik jest taki, że nie na poziomie akceptacyjnym - czyli jako "nadbudowa" nad scenariuszami.
A właśnie na poziomie jednostkowym (sic!).
Gdzie SbE jest formą wyrażenia kontraktu/niezmienników dla Agregatów - bo dobrze zaprojektowana granica agregatu powoduję, że naturalnym unitem w unit testach jest właśnie agregat.
Prześlij komentarz