Curso SDD 002 - Análisis comparativo SDD frente a TDD y BDD ⚫①)

Curso sobre Spec Driven Development 🟡③

El desarrollo de software moderno se articula en torno a metodologías guiadas por diferentes artefactos centrales: las pruebas unitarias (TDD), el comportamiento del usuario (BDD) o la especificación técnica entendida como contrato formal (SDD).

Comprender sus diferencias, sus puntos de sinergia y sus fricciones es clave para determinar cómo influyen en el ciclo de vida del software.

1. Matriz de Conceptos Fundamentales

Cada metodología propone un motor de desarrollo distinto y se orienta a diferentes actores dentro del ciclo de vida del proyecto.

2. Flujo de Trabajo Comparado

La secuencia en la que se ejecutan las fases define el impacto técnico de cada enfoque.

El ciclo Red-Green-Refactor en TDD

El desarrollo técnico se rige por un bucle iterativo a bajo nivel:

1. Red: Escribir una prueba automatizada para una funcionalidad mínima que aún no existe; la prueba debe fallar de forma controlada.

2. Green: Escribir la cantidad mínima de código de producción necesaria para que la prueba pase.

3. Refactor: Optimizar el código interno garantizando que las pruebas se mantengan en verde.

El ciclo de Descubrimiento y Colaboración en BDD

Se enfoca en la comunicación antes de la implementación:

1. Descubrimiento: El equipo técnico y el de negocio definen el comportamiento de la aplicación mediante ejemplos prácticos.

2. Formulación: Los ejemplos se traducen a historias legibles por humanos y herramientas de automatización mediante archivos con extensión .feature.

3. Automatización: Se vinculan los escenarios de texto con pruebas que guían la escritura del código.

El enfoque Design-First en SDD

Sitúa el diseño de la arquitectura en la primera fase del proceso:

1. Modelado del Contrato: Se define la interfaz técnica (por ejemplo, un archivo openapi.yaml) antes de codificar la lógica del negocio.

2. Gobernanza: Se valida el contrato mediante herramientas de análisis estático (linters) para asegurar el cumplimiento de las directrices de diseño.

3. Paralelización Automatizada: Se despliegan servidores de simulación (mock servers) para los equipos cliente y se generan automáticamente los esqueletos de código (server stubs) para el equipo de backend.

3. Convergencias, Sinergias y Fricciones

Estas metodologías no se excluyen mutuamente; en arquitecturas de sistemas complejos, suelen operar a distintos niveles de abstracción.

Coexistencia Arquitectónica

En ecosistemas de software maduros, es común estructurar el desarrollo combinando los tres enfoques de la siguiente forma:

• Perímetro de Red (SDD): Gobierna las interfaces externas y los puntos de entrada/salida de los servicios mediante contratos OpenAPI.

• Capa de Dominio (BDD): Asegura que las reglas y flujos de negocio se cumplan según lo acordado con los stakeholders.

• Capa de Implementación (TDD): Garantiza la corrección algorítmica y estructural de cada clase o función individual.

Puntos de Fricción y Crítica Técnica

El Origen del Diseño

El enfoque SDD puro suele ser de tipo Producer-Driven (el proveedor del servicio define y publica el contrato). Esto plantea un conflicto potencial con el enfoque de Contratos Guiados por el Consumidor (Consumer-Driven Contracts), donde se defiende que las interfaces de las APIs deben evolucionar a partir de las necesidades específicas de quienes las consumen, evitando que el proveedor diseñe contratos aislados de la realidad operativa.

El Coste de Gestión en Entornos Cambiantes

Durante las fases de prototipado rápido o desarrollo de Productos Mínimos Viables (MVP), donde los requisitos cambian con alta frecuencia, la rigidez del SDD puede penalizar la velocidad. Modificar la especificación, validar los esquemas y regenerar el código constantemente introduce un coste de gestión administrativa (overhead) superior al de la iteración directa sobre el código mediante TDD o BDD.

4. Criterios de Selección de Enfoque

La prioridad dada a cada metodología depende de la naturaleza del sistema y de la estructura de la organización:

• Se debe priorizar el SDD cuando se diseñan arquitecturas de microservicios, sistemas distribuidos o entornos orientados a eventos, donde equipos independientes necesitan trabajar en paralelo con un contrato técnico estable y predecible.

• Se debe priorizar el BDD cuando la lógica de negocio es compleja, está sujeta a normativas estrictas o requiere una validación constante con perfiles no técnicos del proyecto.

• Se debe priorizar el TDD cuando se desarrollan componentes de software con alta carga matemática o algorítmica, como librerías de infraestructura o motores de cálculo aislados.

Modelado de Costes y Cobertura

Si evaluamos la eficiencia del sistema, podemos modelar el coste total de calidad ($C_T$) como la suma de los costes de prevención ($C_p$) y los costes de fallo ($C_f$):

$$C_T = C_p + C_f$$

En un entorno SDD, la inversión en prevención es mayor en las fases tempranas del desarrollo, reduciendo los fallos de integración en etapas avanzadas mediante la verificación formal del esquema:

$$V_{esquema} = \sum_{i=1}^{n} (E_i \times P_i)$$

Donde $E_i$ representa el elemento de la especificación técnica validado y $P_i$ el peso de dicho componente en la interfaz global del sistema.

5. Referencias Bibliográficas

Fuentes que apoyan y fundamentan el enfoque SDD

• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Tesis doctoral, Universidad de California, Irvine. Desarrolla las bases del estilo REST y subraya la necesidad de interfaces uniformes y contratos estables en sistemas distribuidos.

  • Enlace al documento original: UC Irvine Repository

• Geewax, J. J. (2021). API Design Patterns. Manning Publications. Analiza la importancia de aplicar especificaciones formales y rigurosas para asegurar la consistencia y escalabilidad en arquitecturas de servicios.

  • Enlace de referencia: Manning Publications

• AsyncAPI Initiative. AsyncAPI Specification Documentation. Documentación técnica oficial que define el estándar protocol-agnóstico para la aplicación de desarrollo guiado por especificaciones en arquitecturas orientadas a eventos.

  • Enlace a la documentación oficial: AsyncAPI Specification

• Postman Engineering. Building an API-First World. Recurso audiovisual técnico que detalla la adopción práctica de especificaciones OpenAPI dentro del ciclo de vida de ingeniería.

  • Vídeo de referencia en el canal oficial: Postman YouTube Channel

Fuentes que cuestionan, matizan o discuten las limitaciones del SDD

• Fowler, M. (2006). Consumer-Driven Contracts: A Service Evolution Pattern. Artículo de referencia técnica que analiza cómo los contratos impulsados exclusivamente por el proveedor pueden generar acoplamientos rígidos, proponiendo en su lugar el diseño guiado por el consumidor.

  • Enlace al artículo técnico original: MartinFowler.com

• Thoughtworks. (2020). Technology Radar: Over-ambitious API gateway logic. Informe de tendencias técnicas que advierte sobre el riesgo de centralizar excesiva lógica operacional y de validación automática en capas de middleware basándose únicamente en especificaciones formales.

  • Enlace al radar de tecnología: Thoughtworks Technology Radar

• Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley. Texto fundamental sobre automatización que, si bien defiende los despliegues continuos, expone los riesgos asociados a las herramientas inmaduras de generación automática de código a partir de esquemas.

  • Enlace de referencia: O'Reilly Learning Platform

One More Thing

¡Desbloquea el poder de MetsuOS y descubre que la privacidad y la seguridad son la clave para desencadenar tu verdadero potencial en línea!

Contenido registrado en Safe Creative

¡Usa el código de promocional 7ZYM4Z y ahorrate unos eurillos en tu suscripcion de Safe Creative!

MetsuOS Needs You!

Apoyanos en este proyecto difundiendolo en tus redes, o mejor, haznos una donación a la cuenta paypal para poder dedicar más tiempo y recursos a el. No olvides comentarnos que parete te interesa más junto con tu donación.

En este momento, además de mantener los servicios, estoy centrado en crear la siguiente iteración del software que me permite hacer todo esto y creando una biblioteca personal física para poder contrastar contenido.

Sobre el sistema de validez de un contenido en MetsuOS

Empezando a incorporar los niveles de validación de un contenido (también llamada sabiduría o niveles de conocimiento) ⚫🔴 🟡 🟢 🔵⚪ ¿Qué són?

• ⚫① - Dark1 - Conocimiento en Bruto. Modo Cuñao, hablo pero no puedo respaldarlo.
• 🔴② - Rojo2 - Conocimiento Impulsivo, pasional, "lo mio es lo correcto".
• 🟡③ - Yellow3 - Conocimiento Crítico: se comienza a explorar el hecho de que pueda haber otras perspectivas.
• 🟢④ - Green4 - Conocimiento Natural: Surge al comprender la naturaleza de la realidad y del ser humano en una materia.
• 🔵⑤ - Blue5 - Conocimiento Científico: Supone la suma de las fases anteriores aplicando el rigor de lo descubierto por la ciencia hasta ahora, sin caer en la -anticientífica- "opinión científica/opinión de expertos".
• ⚪⑥ - Light6 Conocimiento Consolidado: Se alcanza al integrar todo lo anterior desde una perspectiva empática y asumiendo una verdad probabilística dinámica dependiente del contexto.

Sobre la categorización de los tipos de conocimiento

• Conocimiento Gnoseológico: ⚫① 🔴② 🟡③ 🟢④
• Conocimiento Epistemológico: 🔵⑤
• Conocimiento Metsukeológico: ⚪⑥

La Metsukeología (de Metsuke vision global y logos conocimiento) es la ciencia que estudia el conocimiento como un conjunto potencial de conocimiento del que podemos obtener, procesar o percibir partes concretas dentro de un marco contextual específico, y cuyo contexto general real está muy por encima de lo que somos capaces, como especie, de percibir, procesar e integrar de forma completa (definición en progreso).

La Metsucología (de Metsu aniquilación - en este contexto en forma de colapso - , logos conocimiento) es la ciencia que estudia como extraemos verdades percibidas - colapsadas - como conocimiento desde nuestra perspectiva real (tanto epistemológico como gnoseológico) al tomar una parte específica del conocimiento metsukeológico potencial enmarcado en un contexto concreto, obligando a colapsar el conocimiento potencial en conocimiento específico (definición en progreso).

Mas sobre el contexto

DISCLAIMER: Mi consideración de anticientífico respecto al consenso científico es una hipotesis de trabajo propia, que supone que toda asignación de validez, incluso aquella derivada de la conclusión por acumulación de evidencia NO debe ser supeditada a debate, ni acuerdo, debe ser algo probabilistico sin intervención del ego humano. Podría estar equivocado y, en este punto, es donde se aplicaría entonces ese mismo consenso que ahora considero no valido (incluso dañino)

Existen indicadores para algunas cuestiones adicoinales como los siguientes:

• 🌐 - Contenido Externo sobre cuya validez/validación no tenemos control (usualmente enlaces que salen de #MetsuOS)
• ⚖️ - Analisis
  • ⚖️📚 - Análisis Bibligráfico
  • ⚖️🔬 - Análisis Científico
  • ⚖️🏛️ - Análisis Estructural
  • ⚖️🧠 - Análisis Filosófico
• 📖 - Referencia
  • 📖📚 - Referencia Bibliográfica / Libro
  • 📖🔬- Referencia Científica / Paper
  • 📖🏛️ - Referencia Estructural
  • 📖🧠 - Referencia Filosófica
• 🔍️- Paradigma

Cuando hablamos de un contenido que incluye un texto que hace referencia a otro.

• 🔴②-🌐🟡③ - Nivel del contenido del documento Rojo2, nivel del contenido externo del que habla el documento Yellow3.
• 🔴②-⚖️📚 🔴② - Nivel del contenido del documento Rojo2, en base a análisis bibliográfico nivel Rojo2

También aplicaremos el Sistema de fiabilidad de fuentes y credibilidad de contenidos de la OTAN 🔴②, este sistema incluye una valoración de la fiabilidad de la fuente de A a F (siendo A la de mayor fiabilidad) y una varloración de credibilidad del contenido de 1 a 6 (siendo 1 la mayor credibilidad).

En MetsuOS la agregaremos al final uniendo amos valores como si fuera una coordenada. Por ejemplo: ⚫①-D4 o 🟡③-B2. Esto ayudarña a contextualizar la información sobre la solidez del conocimiento al que se hace referencia en cada momento.

Hay que tener en cuenta que, cuando hay elementos subjetivos o parcialmente subjetivos, el punto de referencia seré yo mismo. Quizá más adelante pueda objetivizar esto más (seria lo deseable), pero en tanto no tenga herramientas que me lo permitan, debo ceñirme al principio de honestidar intelectual, y esperar que mis sesgos dañen lo menos posible la información (en parte este es el nudo gordiano que pretendo resolver, y por ello es dificil resolverlo a priori).

Así de forma resumida, podríamos decir que esta definición es nivel 🔴② (Rojo2 xD) ¿Crees que me dejo algo? Si es así por favor ayudame a mejorarlo contactándome a través de X (Twitter) en mi cuenta, @metsuke 🌐

Consulta la versión completa de la descripcion en ⚫🔴🟡🟢🔵⚪ (🔴②) Un poco más de detalle

• Información IA: Pendiente de Definición
• Ultima Modificación: 2026-06-09 20:02:25.345000+00:00
• Versión Documento: 0.1.1