Destilando el dominio de negocio

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

May 10, 2025 - 17:50
 0
Destilando el dominio de negocio

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