DOMAIN-DRIVEN DESIGN VS ARQUITECTURA HEXAGONAL

¿Qué es Domain-Driven Design (DDD)?

El Domain-Driven Design es un enfoque de diseño propuesto por Eric Evans. Objetico: "Poner el dominio del negocio en el centro de la aplicación y modelarlo de la forma más fiel posible al lenguaje que usan los expertos del negocio".

Características principales de la arquitectura DDD

  • Se centra en el modelo del dominio.
  • Utiliza el lenguaje ubicuo (Ubiquitous Language).
  • Divide el sistema en Bounded Contexts.
  • Introduce patrones tácticos como:Entities
  • Value Objects
  • Aggregates
  • Domain Services
  • Repositories
  • Domain Events
La arquitectura DDD responde a la pregunta: "¿Cómo modelamos correctamente las reglas y el lenguaje del negocio en el código?"

¿Qué es la Arquitectura Hexagonal?

La Arquitectura Hexagonal, también conocida como Ports and Adapters, fue propuesta por Alistair Cockburn a principios de los años 2000. Objetivo:"Aislar el núcleo de la aplicación (lógica de negocio) de todos los detalles técnicos externos (base de datos, frameworks, interfaces de usuario, APIs externas, etc.)".

Características principales de la arquitectura Hexagonal

  • El núcleo de la aplicación no conoce nada del mundo exterior.
  • Se comunica con el exterior a través de Puertos o interfaces.
  • Las implementaciones concretas se llaman Adaptadores.
  • Existen dos tipos de adaptadores:
    • Primarios (Driving): Los que impulsan la aplicación, como HTTP, CLI, mensajes, etc-.
    • Secundarios (Driven): Los que utilizan, como base de datos, envío de emails, colas, etc.
La arquitectura Hexagonal responde a la pregunta: "¿Cómo protegemos el núcleo de la aplicación de los cambios tecnológicos y de los detalles de infraestructura?".

Diferencias clave entre la arquitectura DDD y la arquitectura Hexagonal

Aspecto DDD Arquitectura Hexagonal
Naturaleza Enfoque / Metodología de diseño Estilo de arquitectura
Enfoque principal Modelado del dominio y del negocio Aislamiento y desacoplamiento técnico
Pregunta que responde ¿Qué modelamos y cómo lo modelamos? ¿Cómo protegemos el núcleo de lo externo?
Conceptos centrales Aggregates, Value Objects, Bounded Contexts, Ubiquitous Language Ports, Adapters, Primary/Secondary
Nivel de abstracción Alto (estratégico + táctico) Medio-alto (estructural)
Habla de capas Sí (Domain, Application, Infrastructure…) Sí, pero de forma más estricta (núcleo aislado)
Dependencia de frameworks El dominio no debe depender de ellos El núcleo no debe depender de ellos
Se puede usar solo Sí Sí
Complementariedad Muy alta Muy alta

¿Cuándo usar cada arquitectura?

Situación Recomendación
Dominio complejo con muchas reglas de negocio DDD (imprescindible)
Quieres independencia de frameworks y bases de datos Arquitectura Hexagonal
Dominio complejo + quieres máxima mantenibilidad DDD + Hexagonal (la mejor opción)
Aplicación simple tipo CRUD Ninguna de las dos es realmente necesaria