Detalles sobre el dominio

Detalles sobre el dominio

El dominio es la razón de ser del sistema.

Tiene varios nombres:

• Lógica de negocio.
• Lógica de dominio.
• Negocio.

“El dominio involucra lo que debe hacer el negocio, haya o no sistemas de información”.

Ejemplo: Un sistema de supermercado.

• Calcular descuentos.
• Verificar inventario.

• Si los empleados usan una aplicación web o una consola para procesar una compra.
• Si los empleados tienen lectores de códigos de barras o no.

Situaciones a evitar con el dominio

• Referenciar la capa externa desde el dominio.

  import Correo from 'external';
  
  const Servicio = () => {};
  

• Mencionar elementos de la capa externa.

  function notificarUsuario() {
  	let enviarSMS = true;
  	// ...
  }
  

• Retornar datos con un formato específico.

  return '<span>Cliente ' + 'no existe</span>';
  

• Permitir que la lógica de negocio se filtre.

  • Se tiene un botón “Guardar usuario” en un formulario y en el manejador de evento de click pueden ocurrir cosas como:
    • Validar campos del formulario.
    • Validar si el usuario existe.
    • Decide si insertar el usuario o actualizarlo.

Formas de organizar el dominio

• Script de transacción.
• Modelo de dominio.
• Capa de servicios.
• Casos de uso.
• CQRS.

🎯Key takeaways

Recuerda que

• El dominio es el elemento central. Hay que cuidarlo mucho.
• Cuando hablamos del dominio, nos referimos a la lógica del negocio.
• El dominio es aquello que debe hacer el negocio, exista un sistema informático o no.
• Debemos mantener fuera del dominio elementos cambiantes que no corresponden a la lógica (el tipo de aplicación, hardware)

🙅🏻 Evitemos

• Referenciar la capa externa desde el dominio. Es decir no hay que usar o importar paquetes u otros elementos en el código referente al dominio
• Mencionar elementos de capa externa. Hablamos de escribir código con consideraciones y terminología que solo se debería conocer en la capa de arquitectura. No se debe asumir qué tecnología, librería, paquete o función se está usando en las capas externas. El código del dominio debe ser agnóstico.
• Retornar datos con un formato específico de implementación. El dominio no debe encargarse de preparar los datos en un formato especial para que pueda usarse por el código de capas externas. Al hacer esto, el dominio queda atado (acoplado) a la forma en que se implementa (detalle de implementación) y complica la reutilización (el dominio queda comprometido)
• Filtraciones de la lógica. Asegúrate que la lógica de negocio no salga del dominio. Las capas externas no deberían encargarse de la lógica que debe hacer el dominio. En el caso de validaciones de campos, la UI puede encargarse de eso como apoyo de UX, pero deberían realizarse también en el dominio ya que la responsabilidad es del dominio, mientras que la UI es un apoyo para que el usuario interactúe fácilmente con las reglas de dominio que el sistema disponga.

🗂 Podemos organizar el dominio con la ayuda de

• Script de Transacción
• Modelo de Dominio
• Capa de Servicios (complementa muy bien al modelo de dominio)
• Casos de uso
• CQRS

@Manuel en este video me parece interesante lo que hiciste, pero le dieras más valor si explicaras como fuera la contraparte de cada ejemplo, en este caso lo que debe poner correctamente

✅