Come funziona lo sviluppo comportamentale (BDD) con Domain Driven Design (DDD)

Question

La mia comprensione di BDD è quella che descrive un sistema in user story e quindi gli sviluppatori prendono quelle user story e le trasformano in un'applicazione con l'intenzione di aggiungere valore di business reale con ogni "sprint" (periodo di sviluppo del software). Il risultato (per quanto ne so io) è che il modello di dominio emerge dalle storie utente durante il processo di sviluppo. Cioè, dopo il primo 'sprint' gran parte del modello di dominio non sarà stato progettato.

La mia conoscenza della DDD è che lo sviluppo del software continua con riferimento a un modello di dominio completo, anche se in evoluzione. Nel DDD il modello dovrebbe cambiare, ma è comunque "completo" in ogni momento.

Questa sembra essere una differenza fondamentale tra i due approcci. Come hanno gestito la gente questo?

Answer 1

BDD eseguito correttamente non produce un modello "completo". C'è una ragione per cui Dan North, il ragazzo che ha inventato il BDD, chiama il suo blog "embracing uncertainty".

Trovo utile in questi giorni pensare a tre tipi di cose che possiamo analizzare: il conosciuto, il conoscibile e l'inconoscibile.

Le cose note sono semplici, ad esempio l'accesso. È ben compreso. Non abbiamo bisogno di parlare attraverso gli scenari.

Le cose conosciute sono solitamente correlate al dominio o a qualcosa che è stato fatto prima. Questo è un ottimo posto dove fare BDD, perché aiuta a trasferire le conoscenze - incluso il modello di dominio - dal business agli sviluppatori. Parlare attraverso gli scenari è un ottimo modo per capire meglio le storie. Può anche aiutarci a trovare gli scenari che abbiamo perso. Chris Matts, che è l'analista che ha contribuito a mettere il "dato" in "Given, When, Then" chiama questo "rottura del modello". In realtà offriva premi a chiunque riuscisse a inventare uno scenario che non era coperto dal suo modello, che utilizza per definire e perfezionare gli scenari.

C'è anche la roba inconoscibile. Questo succede quando lavoriamo su qualcosa di nuovo, o qualcosa che non abbiamo mai fatto prima, o qualcosa in cui nessuno ha esperienza. Puoi dire se sei in questo posto perché gli uomini d'affari inizieranno a reagire con sorpresa quando ti verrà in mente gli scenari a cui non hanno pensato. BDD è un ottimo modo di trovare in questi luoghi, ma a questo punto probabilmente vorrai smettere di cercare di definire gli scenari e provare semplicemente qualcosa e ottenere invece un feedback. Il tuo modello di dominio, le tue storie utente e i tuoi scenari emergeranno gradualmente (see the complex domain in the Cynefin model).

So che molte squadre usano BDD come un modo per eliminare apparentemente questa incertezza. Non puoi eliminarlo. Puoi nasconderlo solo più tardi, quando il feedback dalla consegna torna a morderti.

Per quanto riguarda DDD, quando lo facciamo con BDD si tende a concentrarsi su quelle parti del modello di dominio che sono rilevanti per gli scenari su cui stiamo lavorando, anche se potremmo avere un'idea del dominio più grande modello nel complesso. Se stai utilizzando Feature Injection insieme a BDD, avrai già parlato attraverso la maggior parte delle funzionalità del sistema, in particolare quelle nuove, così avrai un'idea di che tipo di cose ci sono nel dominio. L'evoluzione e tutte le altre regole si applicano ancora. BDD e DDD funzionano davvero, molto bene insieme, con conversazioni su scenari che aiutano a far emergere la lingua del dominio. Non sono fondamentalmente diversi, ma completamente di supporto e compatibili.

Si prega di leggere anche the answer I gave to this similar question, che presenta un video di Dan Nord e me stesso che parla di questo argomento.

Answer 2

Includerei user story, DDD e BDD poiché sono molto dipendenti l'uno dall'altro. Ho cercato di riassumere il link qui: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/

Spero che questa immagine è semplice e abbastanza ricco per spiegare il legame tra questi "concetti"