Ideea e simpla: se introduc concete tehnice, apoi luam o aplicatie si incercam sa o modelam impreuna, pt a invata trial-and-error cum se face, si la ce ne uitam.
Scopul e sa o facem alaturi de manageri de proiect, analisti de business, etc, sa prinda si ei gustul
Mie mi se pare genial Test Driven Development, m-am uitat la niste cursuri dar am practicat putin, noi scriem teste dupa ce scriem cod, domain driven design cred ca e o chestie mai avansata, nu am nici o idee despre el, probabil de asta nici nu ma atrage.
La closing keynote ZendCon, chiar Cal Evans a recunoscut ca si el functioneaza pe modelul test-last in loc de test-first. Dar acela nu e TDD. Uncle Bob a recunoscut de mai multe ori public ce mult l-a schimbat tdd ca programator.
DDD e o metoda minunata de a dezvolta aplicatia pe baza nevoilor de business, prin identificarea conceptelor de business (asa-numitul domain), si arhitecturi hexagonale, in care baza de date sau un api extern sunt deferred until the last moment. Se merge pe ideea de descoperire a domeniului de business si a evenimentelor la care se face trigger, ma refer aici la evenimente tip “userul face checkin”. Acestea se diseca, intelegand ca “user” inseamna diferite lucruri in diferite contrxte, deci creem mai multe entirati user, cate una pt fiecare boundary (daca difera intre ele).
E foarte potrivit pentru a face discovery phase si a nu arunca acel cod; dimpotriva, se itereaza modelele pana se trece din MVP in produs finit. Am patit ca refactoring la nivel de business scenario (aka s-a razgandit clientul) sa fie muuuuult mai eficient dpdv a costului de implementare, tocmai pt ca aveam ddd in place. [Sper ca am fost coerenta dupa multe ore de zbor across the globe]
16 pica in mijlocul unei saptamani de scoala. Mai complicat. Pentru Bucuresti ai de gand sa tii un astfel de workshop? De cati participanti ai avea nevoie?
Ce are în comun tdd,ddd,bdd?
Comunicarea cu cei care știu domeniul pentru a identifica conceptele și comportarea acestora, iar cea mai bună este cea vizuală, care înseamnă nu doar că pot vedea persoanele participante în diferite sesiuni de brainstorming ci și că pot vedea pe un stickies notes conceptele scrise puse pe un zid și de acolo putem să încingem conversațiile despre domeniul respectiv.
Dar încearcă să faci așa ceva fără access la domain experts, sau ei sunt remote, sau compania nu este agile cu adevarat.
Probabil se face ceva hacky, fără nici o sesiune de design al conceptelor importante de business, iar când lucrurile nu mai avansează ca la început sau mai rău sunt pe cale să dea faliment, atunci vor aduce pe cine care să-i consilieze cum pot derge busuiocul, iar atunci probabil se face o sesiune de big picture ca și event storming să vadă unde este cu adevărat problema și de unde trebuie să se facă un refactoring.
O serie interesantă despre modeling a Domain from Event Storming all the way to a CQRS/Event Sourced architecture.
de la Nick Chamberlain.
Mi-ar plăcut să vin și eu, dar din păcate nu pot.
Multă baftă.
Aș putea să încerc să vin și la București cu workshopul ăsta. Va trebui să mă ocup de logistică, dar mi-ai dat o idee chiar bună.
Ca număr de participanți, un maxim ar fi 10, ca să existe eficiență. Pentru că fiecare va trebui să participe activ, un număr mai mare implică diluarea mesajului din cauza overheadului mare provenit de la discuții.
Pune la cale un astfel de workshop cu o înregistrare serioasă (atât audio cât și video) și pune-l la închiriat pentru cei care nu vor/pot să plece din oraș
Da, logistica e mult mai scumpa in capitala. Ma voi gandi eventual la organizarea la sediul unei companii, si gratuizarea accesului angajatilor lor, asa ar putea functiona. Nevoile sunt doar de un proiector, si multe-multe sticky notes pe un roll lung de hartie / perete.
Imi place acest workshop. Cand faci in Bucuresti sa ne anunti, mai vin cu o persoana.
Daca scrieti cod PHP va recomand si https://leanpub.com/ddd-in-php