tag:blogger.com,1999:blog-5197374494377847819.post4809534482272280713..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Połączenie BDD z DDDSławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5197374494377847819.post-51968427153648225732015-04-06T23:08:01.757+02:002015-04-06T23:08:01.757+02:00o to, to, właśnie!
Co do metodyki postępowania to...o to, to, właśnie!<br /><br />Co do metodyki postępowania to parę razy fajnie sprowadziło się podejście ze Spec by Example.<br /><br />Ale trik jest taki, że nie na poziomie akceptacyjnym - czyli jako "nadbudowa" nad scenariuszami.<br /><br />A właśnie na poziomie jednostkowym (sic!).<br />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. Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-9793759078534921312015-04-05T22:38:11.452+02:002015-04-05T22:38:11.452+02:00Masz rację wiele zależy od osób ich cech co przekł...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.<br /><br />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.<br /><br />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)<br /><br />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..<br /><br />Pytanie czy w miarę podobnie postępujesz czy masz jakiś innych schemat działania :) ?<br /><br />---<br /><br />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 ...)Anonymoushttps://www.blogger.com/profile/16464490848045572327noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-59279847005029491172015-04-04T14:50:19.260+02:002015-04-04T14:50:19.260+02:00Odnośnie pierwszego pytania:
Zacznijmy od ustaleni...Odnośnie pierwszego pytania:<br />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ść.<br /><br />Chcąc integrować BDD z DDD (i odnosząc się do przykładu z linka) będziemy formułować na poziomie modelu domenowego.<br /><br />Powstanie coś typu:<br />krok1<br />krok2<br />krok3<br />krok4<br /><br />Ale<br />w DDD mamy monad modelem domenowym jeszcze model procesu w warstwie serwisów aplikacyjnych.<br />I powiedzmy, że z wymagań wyniknie taki podział:<br /><br />serwis1{<br /> krok1<br /> krok2<br />} <br /><br />serwis2{<br /> krok3<br /> krok4<br />} <br /><br />I tutaj pojawia się pewien zgrzyt... z jednej strony mamy logikę z historyjkach (technicznie chcielibyśmy je odpalać jako testy - scenariusze akceptacyjne)<br />ale mamy ją też w serwisach.<br /><br />Zmiana flow pociąga za sobą zmianę w serwisie i w scenariuszu akceptacyjnym.<br /><br />Ale problem jest zupełnie inny - koncepcyjny! Dlaczego nasze scenariusze akceptacyjne są zbudowane na warstwie domeny a nie aplikacji?<br />Wydaje mi się, że to zostało pomieszane i w ogóle przeoczone w komentowanym przeze mnie artykule.<br /><br /><br /><br />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.<br /><br />Mi chodziło wciąż o story. Jeżeli story jest sformułowane tak jak piszesz, na poziomie reguł biznesowych to ok.<br />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.<br /><br />Spróbuję wyjaśnić na przykładzie:<br />mamy 3 reguły i czasem przepływ będzie r1, r3, a czasem r1, r2.<br /><br />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.<br /><br />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ć;)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-88628472121959810072015-04-03T22:09:14.092+02:002015-04-03T22:09:14.092+02:00"Historyjka powiela logikę wyższej warstwy.&q...<i>"Historyjka powiela logikę wyższej warstwy."</i> Mógłbyś bardziej rozjaśnić ?<br /><br /><i>"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ć?"</i><br /><br />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.<br /><br />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.<br /><br />Anonymousnoreply@blogger.com