Diseño de productos de software

En este articulo quiero mostrar como veo el diseño de software, algo que vas mas allá de la parte de programar.
Compartiré mi opinión y mis referencias

Muchas veces cuando hablamos de diseño de software nos vamos directamente a la parte tecnica.
Que stack utilizar, que arquitectura implementar...Cuando quise mejorar como desarrollaba software empecé por la esta parte.
Libros como Clean Code, Clean Architecture o los principios SOLID me dieron la base.

Pero creo que el diseño de software va mas allá de eso y cuando me leí los libros azul y rojo de Domain-Driven Design me quedo bastante claro.

Domain-Driven Design

Es un enfoque de trabajo donde, para el desarrollar software, el foco principal es el dominio de negocio.
Segun esto, el entendimiento entre la parte de negocio y la parte técnica es crucial para que un producto salga adelante con exito.

Para esto se pueden definir una serie de principios que luego se aplican en dos partes: estrategica y tactica.

Principios

• Hacer lo implicito, explicito. Evitar la ambigüedad
• Crear un lenguaje común entre todos los involucrados en el proyecto
• Mantener una actitud de aprendizaje continuo, el dominio no es estático y siempre hay cosas por aprender o mejorar
• Explora diferentes modelos del dominio, no te quedes con la primera idea
• Focalizarse en escenarios concretos. Expón tus modelos a esos escenarios
• Diseño evolutivo. Como el dominio no es estatico y el diseño es un reflejo del mismo, este cambiará con el. Mantener un ciclo constante de prueba y validación te va a ayudar

Parte estratégica

Se centra en comprender el negocio y definir el contexto en el que opera el software. Esto incluye:

• Dominio: El área de conocimiento o actividad empresarial a la que se aplica el software.
• Contexto Delimitado (Bounded Context): Límite semántico alrededor de una parte del dominio, donde un modelo particular tiene sentido.
• Lenguaje Ubicuo (Ubiquitous Language): Un lenguaje común compartido por los expertos del dominio y los desarrolladores para describir el dominio.
• Mapas de Contexto (Context Maps): Las relaciones entre los diferentes contextos delimitados.

Parte táctica

Esta centrado mas en diseñar e implementar el software utilizando patrones y prácticas específicas. Esto incluye:

• Entidades (Entities): Objetos con identidad única y ciclo de vida.
• Objetos de Valor (Value Objects): Objetos inmutables que representan conceptos del dominio.
• Servicios de Dominio (Domain Services): Operaciones que no encajan naturalmente en entidades u objetos de valor.
• Agregados (Aggregates): Clústers de objetos que se tratan como una sola unidad para la consistencia de datos.
• Repositorios (Repositories): Mecanismos para persistir y recuperar agregados.
• Eventos de Dominio (Domain Events): Registros de cosas que sucedieron en el dominio.

Opinión personal

A grandes rasgos este es el enfoque que prefiero dar cuando diseño software.
La implementacion de la parte tactica puede variar dependiendo de su complejidad o si tienes un enfoque mas funcional u orientado a objetos a la hora de desarrollar pero la parte estrategica es vital.

Por ultimo, se que muchos ven este enfoque valido solamente para proyectos complejos pero en mi opinion la complejidad solo te obliga a ser mas metódico, los principios se pueden aplicar y van a aportar beneficios en cualquier proyecto.

Referencias

Voy a dejar más contenido sobre el tema. Aparte de los libros mencionados que recomiendo muchísimo.

DDD Crew repositorio de github con mucho contenido relevante para DDD

Domain-Driven Design Europe organizan conferencias cada año sobre DDD y su canal de youtube tiene videos muy interesantes

Cualquier libro de la serie Addison Wesley Signature