BDD e DDD funzionano bene insieme?

7

Lo sviluppo comportamentale (BDD) può essere descritto come in questo post del blog come segue:

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this, they can agree to a common definition of “done”, and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing”.

Quindi sembra molto simile a un modo per gestire i requisiti del software e avere davvero un'idea chiara di ciò che deve essere sviluppato e dei criteri per stabilire se è stato sviluppato correttamente.

Il Domain-Driven Design, d'altra parte, è uno sforzo di modellizzazione, che pone l'accento sulle regole del business e sulla costruzione di un linguaggio ubiquo. Domain-Driven Design fornisce idee molto belle su come per strutturare il codice, come per rompere un dominio complesso in parti più piccole (con contesti limitati) e come per comprendere diversi "tipi" di oggetti che potrebbero essere necessari nella codifica, definendo precisamente entità, aggregati e così via.

Risulta che DDD non dice molto (per quanto ne so), se dice qualcosa, su come gestire i requisiti del software.

Come collegare l'organizzazione dei requisiti e la nozione di che deve essere sviluppata, per svilupparla effettivamente, al punto che la DDD diventa utile, sembra che DDD non lo dica.

Dato che DDD si concentra sulla costruzione di un linguaggio onnipresente che impiega i termini del business e parla di "capire veramente che cos'è il dominio e ha bisogno", mi è sembrato in un primo momento che BDD e DDD possano andare d'accordo insieme.

Ma questa è una questione di esperienza. L'unico che ha provato può conoscere i risultati.

La mia domanda qui è: qualcuno ha provato a usare sia BDD che DDD insieme? È una cosa giusta da usare poi insieme? Se no, perché non vanno d'accordo contrariamente all'intuizione?

    
posta user1620696 12.05.2017 - 03:07
fonte

1 risposta

8

Come ha già fatto notare @ robert-harvey, il linguaggio ubiquitario è idealmente la forza vincolante comune.

DDD si concentra sulla definizione del vocabolario in quel linguaggio: attori, entità, operazioni, ... Una parte importante del DDD è anche che il linguaggio ubiquitario può essere chiaramente visto anche nel codice, non solo nella comunicazione tra l'implementatore e l'esperto di dominio. Quindi una visione estrema di DDD è abbastanza statica: descrive il sistema finito nel suo insieme.

BDD si concentra sulla definizione di storie di utenti o scenari. È strettamente correlato a un processo incrementale, ma può anche essere visualizzato come statico: descrive tutte le interazioni tra gli utenti e il sistema finito.

DDD e BDD possono essere applicati senza sovrapposizioni: le User story di BDD possono essere scritte usando solo il vocabolario dell'interfaccia utente (pulsanti, etichette, ...), e DDD può evitare di menzionare le interazioni.

Ma idealmente questi due si sovrappongono e lavorano insieme: le storie di BDD sono ricche del linguaggio onnipresente, che descrive l'esperienza dell'utente con concetti di dominio. E DDD si assicura che le storie possano essere trovate nel codice.

    
risposta data 12.05.2017 - 07:25
fonte

Leggi altre domande sui tag