Domain Driven Desing

En un mundo donde los requerimientos cambian con frecuencia, se necesitan diseños que permitan cambiabilidad constante sin depender de las tecnologías, en caso contrario se puede incurrir en graves problemas de diseño, tornándose este último demasiado rígido.

Definición de DDD

Domain driven design es un enfoque para el desarrollo de software definido por Eric Evans en su libro Domain-driven design: Tackling Complexity in the Heart of Software, que se centra en un modelo rico, expresivo y en constante evolución para resolver problemas del dominio de una forma semántica.

¿Qué se busca con DDD?

  • Disminur la regidez del diseño ya que se busca desacomplar la lógica de negocio de la tecnología.
  • Tomar decisiones arquitectónicas más acertadas ya que al momento de depender de las tecnologías estas pueden ser erroneas, lo cual puede traducirse en un alto grado de desenfoque del negocio
  • Separar componentes de alto nivel (negocio) con los de bajo nivel (Tecnología)

Antes de comenzar con DDD, primero se deben de hacer las siguientes preguntas:

  • ¿Qué se busca con DDD?
  • ¿Cuál es el dominio del problema?
  • ¿Cuál es el espacio del problema?
  • ¿Cómo se representa?

Dominio

Podría definirse como el área o campo en el que se quiere enfocar el sistema, por tanto el enfoque debe estar centrado en la lógica de negocio y no en la tecnología. en pocas palabras va relacionado con el espacio problema.

Tipos de dominio

  • Transversal: Podría ser la seguridad del sistema.
  • Vertical: Enfocado a ciertos tipos de empresas o negocio.

Lenguaje ubicuo

Entender las nececidades por medio de un lenguaje común usado por el equipo de desarrollo y los expertos del dominio o el negocio

¿Que propone DDD?

Se basa en la técnica «divide y vencerás» ya que en este se manejan contextos limitados (Bounded context)

Contexto limitado

Todos los conceptos que se definan en ese contexto van a tener un significado único para ese contexto.

Contexto delimitado DDD
La forma como se usa vehículo es diferente para cada uno de los contextos de facturación y ventas

¿Cuándo es bueno usar DDD?

  • En software complejo
  • No es bueno usarlo en «aplicaciones simples», por ejemplo proyectos de 1 o 2 meses de desarrollo

El dominio no es único, varía de acuerdo al negocio o a la organización

Elementos relevantes de DDD

  • Entidades (Business Object): Tienen identidad, es decir que el atributo más importantes es el identificador, ya que a través de éste se identifican unívocamente, por tanto este atributo hace que se pueda obtener el estado de ese objeto. En DDD no se puede tener más de una entidad con un mismo identificador.
  • Objeto de valor (Value Object): No tienen una identidad como tal, es para definir las cataracterísticas de una sola cosa, son inmutables, por tanto no tienen métodos set, no son los elementos más relevantes.

En de DDD no se deben tener modelos anémicos (Sólo con getter y setter), por tanto todo, debe tener comportamientos sobre los datos.