El Desarrollo guiado por pruebas (TDD: Test Driven Development) y el Desarrollo guiado por comportamiento (BDD: Behavior Driven Development) son metodologías complementarias que tienen como objetivo asegurar la calidad del software desde la fuente.
Además de tener la aceptación organizacional y una comprensión compartida de estos conceptos entre sus equipos y sus miembros, el paso más importante es comprender cuándo y dónde utilizar estos marcos para garantizar el máximo rendimiento.
Antes de escribir una sola línea de código (o incluso de pensar en ella), debe comenzar por comprender el problema que está tratando de resolver, cómo se creó el problema en primer lugar y, quizás lo más importante, qué valor proyectas la solución a tener. En esta fase de descubrimiento, es mejor hacer uso de preguntas abiertas para determinar qué punto de dolor específico está tratando de aliviar, quién y cómo se beneficiará de él y qué impacto tendrá en la organización. En este punto y si se hace correctamente, debe tener una buena comprensión de por qué este desarrollo es beneficioso y una visión clara de qué construir.
Lo que se busca es “Build the right software” y “Build the software right”. Colaboración y entendimiento colectivo (stakeholders, business analysts, software developers, and testers). Entregar más valor al identificar, entender y construir lo que más importa en el negocio. Entregar software más confiable y efectivo asegurando que el software está bien diseñado y desarrollado.
BDD permite generar conversaciones alrededor de ejemplos concretos para entender cómo los features proveen valor al negocio, Expresar requerimientos de forma más “testeable” en un lenguaje que tanto stakeholders como equipo de desarrollo puede entender y convertir requerimientos en test automatizados que guían el desarrollo, verifican/validan el feature y se convierte en documentación.
Los pasos más importantes son:
Levantar Requerimientos en BDD
Capabilities les da a los usuarios/stakeholders la habilidad de realizar alguna tarea útil o completar algún objetivo comercial. La habilidad de “hacer algo” (independientemente de cómo lo vamos a implementar).
Feature representa una funcionalidad de software que construimos para soportar el capability. Podemos reconocer un feature sí es una acción concreta que el usuario puede realizar en el sistema, algo que cambia el estado del sistema o algo que hace que el sistema interactúe con un tercero (third-party).
Por medio de los talleres de descubrimiento, podemos definir diferentes metodologías como Example Mapping, donde podemos descubrir ejemplos, agruparlos en reglas de negocio y convertirlo en features. A partir de estos ejemplos y features vamos a crear nuestras historias de usuario y construir nuestro escenario que podemos expresar lenguaje Gherkin.
¿Cuál es la mejor manera de abordar un gran proyecto de desarrollo? Lo divide en segmentos más pequeños y manejables, o en el caso de DDD, dominios. Cuando divide el proyecto en dominios más pequeños, puede tener equipos segregados que manejen la funcionalidad de ese dominio de principio a fin. Y para comprender mejor esos dominios, solicita la ayuda de expertos en dominios; alguien que entiende el problema y ese ámbito de conocimiento más que nadie. Por lo general, el experto en el dominio no es el responsable de desarrollar la solución, sino que DDD se usa colectivamente para ayudar a cerrar la brecha de conocimiento que suele existir entre estos expertos y la solución que se intenta realizar. A través de modelos, contexto y lenguaje ubicuo, todas las partes involucradas deben tener una comprensión clara de cuáles son los problemas particulares y cómo se estructurará la construcción resultante.
Domain Driven Design - DDD, es un enfoque de desarrollo que conecta la implementación con un modelo en evolución; colocar el foco del proyecto en el dominio central (esfera de conocimiento), la lógica detrás de él, y obliga a la colaboración entre partes técnicas y no técnicas para mejorar el modelo.
Se centra en investigar, definiendo todos los aspectos necesarios antes de proceder a la codificación.
Quizás uno de los aspectos más difíciles para aprender DDD es poder determinar qué herramienta se necesita para la tarea en particular. En DDD, los repositorios, los mapeadores de datos y los DTO son una parte fundamental del ciclo de vida de la entidad que nos permite almacenar, reconstituir y eliminar entidades de dominio. Este tipo de lógica se denomina "Lógica de acceso a datos".
¿Qué es responsable de manejar la lógica de validación? Objetos de valor.