El DDD se centra en la importancia de entender bien el dominio de nuestro problema, en contraste al enfoque tradicional, centrado en los datos que tratamos. El objetivo es ser experto en el dominio, se modelan todas las entidades y reglas específicas y a partir de ahí, se implementan los casos de uso que lo queremos resolver.

Se recomienda realizar el desarrollo basado en dominio, que en datos… ya que al separar los casos de uso y las reglas de dominio podemos conseguir independencia en los casos de uso que pueden ir cambiando en el tiempo.

• Lenguaje Ubicuo. Es un vocabulario común que describe el dominio del problema: verbos, nombres, adjetivos. Es compartido por todos los interesados del proyecto para evitar malentendido. Se crea a partir de sesiones de brainstorming y análisis del dominio. Se documenta.
• Contextos Acotados. Es común que según un sistema crece, lo más fácil es dividir las funcionalidades por contextos. De tal manera que cada equipo tiene su propia entidad de acuerdo a su contexto. Cada uno tiene su lenguaje ubicuo propio. Al final es un subdominio del dominio.
• Mapeo de contextos.
  • Tipos de relaciones entre contextos:
    • Conformista. No existe ninguna capacidad de negociación.
    • Cliente/proveedor. Dependencia con cierto grado de negociación.
    • Socio. Ambos contextos colanoran por una meta en común, por lo que ambos lados de la relación tiene poder para influenciar al otro.
    • Capa anticorrupción. Interfaz que utiliza Downstream para interactatura con Upstream.

Todo esto se hace con el fin de separar la lógica de aplicación (casos de uso) de la lógica de dominio.

✅ Lenguaje común compartido para perfiles técnicos y no técnicos

✅ El coste de realizar modificaciones suele ser menor, ya que el dominio cambia con poca frecuencia y la velocidad de desarrollo a medio y largo y plazo

✅ El código del dominio es autoexplicativo

❌ Lento al principio de un proyecto

❌ Expertos en el dominio del problema

Se recomienda usar en proyectos complejos con un largo de vida esperado del software. Incertidumbre en los casos de uso o con previsión de cambios en el futuro. NO para una CRUD. Disponibilidad de un equipo comprometido en analizar detalladamente el dominio,

Arquitectura de Capas