DEV Community: Guille Granado

Destilando el dominio de negocio

Guille Granado — Sat, 10 May 2025 16:12:12 +0000

En el articulo anterior estuve comentando sobre como enfocar el diseño de software desde Domain Driven Design (DDD). Aquí voy a profundizar un poco mas en su parte estratégica

Como ya mencionamos el objetivo de la parte estratégica se centra en comprender el negocio.

Para esto DDD define los siguientes conceptos.

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.

Descubrimiento

El objetivo de esta fase es entender cómo funciona el negocio en su conjunto, descubrir el modelo mental de los expertos, identificar Bounded Contexts y sus relaciones. Y con esto crear una visión compartida entre técnicos y negocio.

Para conseguirlo tenemos que reunirnos con los expertos de negocio y entender como funciona y leer la documentación disponible.

Existe una herramienta, llamada Event Storming, muy útil que puede ayudar a entender el dominio, alinear todas las partes y tener un diagrama del dominio que luego se puede usar como referencia.

Una vez tenemos el Dominio y los Bounded Contexts tendremos mucho vocabulario que se ha usado durante todo el proceso.
Esto es el Ubiquitous Language y todas las partes deberán usarlo en todas las fases para evitar confusión.

Se creará un glosario o documento compartido donde se definirá todo este Ubiquitous Language junto con el contexto en el que pertenece.

Con los Bounded Context el siguiente paso es definir como se van a relacionar. Es el momento de definir los Context Maps.
Aquí tenemos diferentes tipos de relaciones:

Shared Kernel: Relación cooperativa entre dos contextos que comparten una parte del modelo.
Customer–Supplier: Un contexto (Customer) depende de otro (Supplier), que le provee un modelo o servicio.
Conformist: El contexto dependiente adopta el modelo del proveedor sin capacidad de influir en él.
Anticorruption Layer (ACL): El contexto receptor se protege de otro contexto mediante una capa de traducción.
Open Host Service (OHS): Un contexto expone su funcionalidad a otros mediante una interfaz pública bien definida.
Published Language: Un contexto publica un lenguaje de integración estándar para facilitar el consumo externo.
Separate Ways: Dos contextos no necesitan coordinarse ni integrarse. Viven aislados.
Partnership: Dos contextos colaboran estrechamente con responsabilidad compartida.

Definir los Bounded Contexts correctamente es desafiante y muy importante ya que va a afectar todo el diseño.
Aquí algunos tips que pueden ayudar:

Hacer la fase de descubrimiento con stakeholders es clave
Detectar diferencias en el lenguaje utilizado por cada área (Ubiquitous Language + Bounded Contexts)
Validar hipótesis de contextos con ejemplos reales del negocio
Usar Context Mapping para definir relaciones explícitas
Incluir tanto al negocio como al equipo técnico en el diseño
No obsesionarse con microservicios = contextos (no es lo mismo)
Refactorizar contextos si el modelo evoluciona (¡están vivos!)

Diseño

En esta fase nos centramos en diseñar el modelo de dominio detallado dentro de cada Bounded Context, traducir lo que hace el negocio en comportamientos del sistema.

Se preparar todo para implementar: entidades, agregados, eventos, comandos, etc.

Con esto estaremos listos para la parte táctica y empezar la implementación.

Opinión personal

Nunca he trabajado en una empresa con un proceso realmente riguroso para documentar esta parte estratégica, o al menos, no he estado involucrado en esas fases.

Lo que sí he visto, una y otra vez, es que cuando estas etapas no se hacen bien, con el tiempo —o con la llegada de nuevas personas al equipo— vuelven la confusión y los errores sobre el dominio y sus contextos.

Contar con glosarios y diagramas generados durante el Event Storming ayuda mucho a compartir una visión común y tener una referencia clara y accesible en todo momento.

Ahora bien, es importante entender que el dominio evoluciona, y su documentación debe evolucionar con él. Eso implica un trabajo constante de mantenimiento. Tal vez por eso no se documenta tanto como se debería: porque una documentación desactualizada puede ser tan problemática como no tener ninguna.

Lo que sí consideraría imprescindible es involucrar a los stakeholders en todo el proceso, documentando todo lo posible para contar con un lugar común de consenso y consulta.

Referencias

DDD reference

Event Storming

Event Storming Glossary Cheat Sheet

Bounded Contexts

Herramienta que puede ser útil para definir los Bounded Contexts.
Bounded Context Canvas

Context Mapping

Diseño de productos de software

Guille Granado — Sun, 09 Mar 2025 16:49:23 +0000

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 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 reference

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

Hola mundo

Guille Granado — Sun, 02 Feb 2025 16:47:17 +0000

Después de tanto tiempo leyendo contenido en esta plataforma y pensarlo mil veces, por fin me he decidido a intentar aportar mi parte aquí.

Soy Guille, desarrollador de software con mas de 10 años de experiencia.
Durante este tiempo he tenido la suerte de involucrarme en una buena variedad de proyectos y tecnologías.
Esto me hace un perfil mas generalista y, aunque tengo tecnologías en las que me siento mas cómodo soy capaz de adaptarme a diferentes proyectos y equipos.

Mi idea con estos posts es intentar compartir lo que hago en el desarrollo de software.
Espero coger el compromiso de ir publicando.

Voy a publicar en español ya que es mi idioma materno y me siento mas cómodo aunque casi toda la información que consumo, y seguramente la que enlace aquí, es en ingles.

No quiero alargarlo mucho, ni si quiera me he preparado este post. Solo me he centrado en publicarlo.

Creo de verdad que me puede venir muy bien y si además le resulta de utilidad a alguien pues mejor que mejor.

Saludos