Diseño de Arriba a Abajo vs. Diseño de Abajo a Arriba
Este artículo es una aclaración de conceptos sobre Top-Down vs. Bottom-Up, incluyendo preguntas de examen, componentes clave y etiquetas.
En Pocas Palabras
- Top-Down comienza con objetivos de negocio y descompone progresivamente en subproblemas e interfaces.
- Bottom-Up parte de componentes existentes (librerías, frameworks, servicios) y los ensambla en una solución.
En la práctica, a menudo Meet in the Middle resulta lo más sensato.
Descripción Técnica Concisa
Top-Down
- Primero objetivos, contexto y casos de uso.
- Luego refinamiento: subsistemas → componentes → clases → operaciones.
- Ventaja: límites claros desde el dominio, pruebas derivadas directamente de requisitos.
Bottom-Up
- Primero reutilización: librerías, SDKs, frameworks, sistemas existentes.
- Luego composición y adaptación.
- Ventaja: inicio rápido, menor esfuerzo de implementación.
Riesgos:
- Top-Down: las restricciones técnicas emergen demasiado tarde.
- Bottom-Up: arquitectura impulsada por tecnología, costos de integración, vendor lock-in.
Puntos Relevantes para el Examen
- Definiciones bien delimitadas.
- Mantener baja el acoplamiento, alta la cohesión.
- Interfaces estables y bien definidas.
- Trazabilidad: requisito → diseño → prueba.
- Adaptadores/Anti-Corruption Layer para componentes externos.
- Meet in the Middle como combinación realista.
Componentes Clave
- Objetivos de negocio + contexto.
- Descomposición en subsistemas.
- Contratos de interfaz.
- Identificación de componentes existentes.
- Adaptadores, fachadas, ACL.
- Objetivos de calidad y reglas arquitectónicas.
- SOLID/GRASP como directrices.
- Estrategia de pruebas (aceptación → unitarias).
- Revisiones de seguridad, dependencias y licencias.
- ADRs (versionamiento de decisiones).
Ejemplo Práctico (Procesamiento de Pagos)
Top-Down:
- Objetivo: autorizar pagos de forma segura.
- Servicios: ServicioPagos, ServicioPedidos.
- Puertos: autorizar(), cancelar().
Bottom-Up:
- Disponible: Payment-SDK, HTTP-Client, Event-Bus.
- Adaptador encapsula SDK.
- Contract Tests contra sandbox.
Meet in the Middle:
- Definir puertos de negocio.
- Llenar adaptadores concretos con SDK.Ventajas e Inconvenientes
Top-Down
- Ventajas: estructura clara del dominio, puertos estables, excelente testabilidad.
- Inconvenientes: fase inicial lenta, riesgos técnicos pueden aparecer tarde.
Bottom-Up
- Ventajas: resultados rápidos, alta reutilización.
- Inconvenientes: riesgo de arquitectura impulsada por tecnología, peligro de acoplamiento y lock-in.
Preguntas Típicas de Examen (con Respuesta Breve)
- ¿Cuál es la diferencia fundamental? Top-Down descompone desde el objetivo; Bottom-Up construye a partir de componentes.
- ¿Cómo afecta esto al acoplamiento y la cohesión? Top-Down fortalece la cohesión del dominio; Bottom-Up puede aumentar el acoplamiento.
- ¿Cómo combinarlos de forma sensata? Meet in the Middle + adaptadores + ADRs.
Estrategia de Aprendizaje
- Dibuja ambos esquemas para un pequeño dominio.
- Define puertos como interfaces.
- Practica Contract Tests contra componentes externos.