BDD bien hecho no produce un modelo "completo". Hay una razón por la cual Dan North, el tipo que ideó BDD, llama a su blog "embracing uncertainty".
En estos días, me resulta útil pensar en tres tipos de cosas que podemos analizar: lo conocido, lo cognoscible y lo incognoscible.
Lo conocido es simple, por ejemplo, iniciar sesión. Está bien entendido. No necesitamos hablar a través de los escenarios.
Las cosas sabidas generalmente están relacionadas con el dominio, o con algo que se haya hecho antes. Este es un gran lugar para hacer BDD, ya que ayuda a transferir conocimiento, incluido el modelo de dominio, del negocio a los desarrolladores. Hablar a través de escenarios es una excelente manera de comprender mejor las historias. También nos puede ayudar a encontrar escenarios que nos hemos perdido. Chris Matts, quien es el analista que ayudó a poner "Dado" en "Dado, Cuándo, Entonces" llama a esto "romper el modelo". De hecho, ofreció premios para cualquiera que pudiera llegar a un escenario que no estaba cubierto en su modelo, que utiliza escenarios para definir y refinar.
También están las cosas incognoscibles. Esto sucede cada vez que estamos trabajando en algo nuevo, o algo que nunca hemos hecho antes, o algo en lo que nadie tiene experiencia. Puedes decir si estás en este lugar porque la gente de negocios comenzará a reaccionar con sorpresa cuando pienses en los escenarios en los que no han pensado. BDD es una gran forma de encontrar estos lugares, pero en este punto es probable que quieras dejar de tratar de definir los escenarios y simplemente probar algo y obtener retroalimentación. Su modelo de dominio, sus historias de usuario y sus escenarios, aparecerán gradualmente (see the complex domain in the Cynefin model).
Sé que muchos equipos utilizan BDD como una forma de eliminar aparentemente esta incertidumbre. No puedes eliminarlo. Solo puede ocultarlo hasta más tarde, cuando los comentarios de la entrega regresen para morderlo.
Con respecto a DDD, cuando lo hacemos con TDC que tienden a centrarse en aquellas partes del modelo de dominio que son relevantes para los escenarios de los que estamos trabajando, a pesar de que podríamos tener una idea del dominio más grande modelo en general. Si usa Feature Injection junto con BDD, ya habrá hablado sobre la mayoría de las capacidades del sistema, especialmente las nuevas, para que tenga una idea de qué tipo de cosas hay en el dominio. La evolución y todas las otras reglas todavía se aplican. BDD y DDD funcionan muy, muy bien juntos, con conversaciones sobre escenarios que ayudan a resaltar el lenguaje del dominio. No son fundamentalmente diferentes, pero completamente compatibles y compatibles.
Lea también the answer I gave to this similar question, que presenta un video de Dan North y yo mismo hablando de este tema.
Gracias Liz, y gracias por las diapositivas en Slideshare. – david004
Mi placer. Aquí está el enlace a las diapositivas del tutorial BDD en caso de que alguien más esté interesado: http://www.slideshare.net/lunivore/behavior-driven-development-11754474 – Lunivore
Muy bien respondida. –