Get best of the week

Diseño de un contexto acotado con un lienzo de contexto acotado: receta del taller

Entre los temas de la próxima conferencia TechLead Conf 2020 habrá una discusión detallada de Diseño impulsado por dominio y EventStorming. Además de preparar un informe de 2 ranuras por Konstantin Gustov sobre DDD , un informe de Sergey Baranov sobre EventStorming y un mitap durante el cual crearemos un radar DDD, decidimos traducir un artículo sobre uno de los métodos más populares para diseñar un contexto acotado.

¿Cómo dividir un sistema grande en componentes más pequeños y manejables? A menudo me hacen esta pregunta, así que reuní mi conocimiento en este artículo.

En DDD, un sistema grande se descompone en contextos limitados (comentario de un traductor: en lo sucesivo se los denominará contextos limitados) , que se convierten en límites naturales, como microservicios en código y como equipos en una organización.

No hay forma de determinar rápida y fácilmente los buenos límites de un contexto acotado. Esto requiere un conocimiento extenso y profundo del negocio y el área temática. Este formato de taller está diseñado para satisfacer ambas necesidades y utiliza dos herramientas para encontrar el diseño de sistema más efectivo: EventStorming y Bounded Context Canvas.

imagen

“Desarrollé este lienzo en el proceso de realizar talleres DDD en eventos públicos y sesiones corporativas. Siéntase libre de cambiar su estructura si encuentra los formatos más adecuados para usted ".

Receta


La receta principal consiste en lo siguiente:

  1. EventStorming (mínimo 1 hora).
  2. Modelar candidatos para un contexto acotado (mínimo 30 minutos).
  3. Modelado del flujo de mensajes de dominio (al menos 30 minutos).
  4. Lienzo de contexto acotado (mínimo 90 minutos).
  5. Creación de mapas contextuales (al menos 45 minutos).

Como punto de partida, recomiendo asignar un día entero para este taller. Esto lo ayudará a comprender cuánto tiempo realmente necesita para realizar el taller correctamente. Si es costoso (lleva tiempo) reunir a todos, intente asignar inmediatamente dos días para hacer todo.

Idealmente, los participantes deberían ser expertos en la materia y expertos técnicos. Si esto es difícil de organizar, intente asegurarse de que los expertos del dominio estén en el taller durante al menos la primera hora.

Principios básicos de modelado


Para realizar una sesión con expertos, necesita una habitación espaciosa. Si elige una audiencia pequeña, lo más probable es que se sienta decepcionado con los resultados. Cada grupo de 4 personas necesitará al menos 4 metros en la pared.

Describiré mi metodología de forma gratuita, sin regulaciones estrictas. Sin embargo, tenga en cuenta:
“Estamos cambiando constantemente entre el espacio del problema y el espacio de la solución. "Estamos buscando información, creando un modelo, buscando información adicional, actualizando el modelo, etc."
Y otro punto importante: el propósito de la sesión es desarrollar opciones y desarrollar la capacidad de ofrecer mejores opciones en el futuro.

1. EventStorming


Para diseñar un sistema, necesita dos cosas: una idea general suficientemente buena de todo el sistema y una comprensión bastante profunda de los detalles en cada área. Para hacer esto, comencemos con EventStorming .

EventStorming es un método de diseño colaborativo que le permite simular una gran área problemática de principio a fin, y también le permite profundizar una gran cantidad de detalles cuando sea necesario.

imagen

Si es la primera vez que hace esto, le recomiendo que reserve 1-2 horas en EventStorming. Después de completar EventStorming, recomiendo dividirse en grupos de 4 personas.
En TechLead Conf 2020, Sergey Baranov hablará sobre la experiencia práctica con EventStorming .

2. Busque candidatos para un contexto acotado.


Después de modelar su dominio de manera amplia y profunda en EventStorming, puede comenzar a agrupar y fusionar fragmentos en un contexto acotado.

imagen

Existen muchos métodos para determinar el contexto acotado. Recomiendo comenzar con lo siguiente:

  • Comience con valor: identifique las partes centrales del dominio que son más valiosas para el negocio.
  • Comience con uno simple : cree un modelo ingenuo dividiendo la línea de tiempo en pasos sucesivos.
  • Busque eventos clave: eventos empresariales que afectan a diferentes partes del proceso empresarial.

Por primera vez, no pase más de 30 minutos en esta tarea. Invite al grupo a crear el modelo de contexto acotado original como punto de partida. No tiene que ser perfecto y es poco probable que sea la solución final.

El resultado debe estar en una lista de nombres de contexto delimitados en un rotafolio o papel. No puede modificar EventStorming físicamente si tiene varios grupos.

Próximos pasos


Puede ver inmediatamente varias formas de modelar el sistema. Por ahora, elija uno de ellos para trabajar y anote otros modelos posibles (serán útiles más adelante). También puede comprender que le falta información de dominio. Si es así, realice otra ronda de EventStorming.

3. Modelado del flujo de mensajes de dominio


Una forma de validar su diseño y buscar puntos de mejora es visualizar la interacción de contextos limitados en escenarios completos del sistema empresarial.

Si el flujo de dominio resultó ser complejo, con una gran cantidad de dependencias y conexiones bidireccionales, entonces su diseño es frágil y necesita más análisis.

Existen muchos métodos de visualización que se pueden usar para modelar flujos y casos de uso, incluidos los diagramas de secuencia UML y los diagramas de casos de uso UML. Recomiendo usar la opción de narración de historias de dominio .

Al modelar el flujo de mensajes de un dominio temático, los contextos acotados son los actores de la historia. Por lo tanto, una historia típica comienza con el usuario tratando de lograr algún objetivo, y la interacción entre contextos limitados tiene como objetivo proporcionar al usuario una solución.

imagen
Un ejemplo ficticio de un flujo de mensajes de dominio El

modelado de flujos de dominio estratégico le permite obtener comentarios sobre los contextos acotados propuestos. Muestra cómo los contextos colaboran entre sí y dependen unos de otros para completar un proceso comercial completo. Esto puede ayudar a encontrar un diseño alternativo.

La pregunta que debe hacerse es si la descripción de cada contexto acotado coincide con el papel que desempeña en la secuencia del dominio. De lo contrario, es probable que el nombre o los límites del contexto requieran un nuevo diseño.

Próximos pasos


Debido a que los flujos de su dominio determinan la relación entre contextos limitados, puede detectar de inmediato defectos de diseño obvios. Puede volver a la acción anterior y actualizar los candidatos para un contexto acotado o realizar una segunda iteración de EventStorming. También puede escribir sus pensamientos sobre el diseño y recopilar más información sobre los próximos pasos antes de comenzar el rediseño.

4. Lienzo de contextos delimitados


La siguiente etapa del diseño es el desarrollo de candidatos para un contexto acotado, utilizando detalles de criterios de diseño clave. Su equipo debe elegir el contexto acotado que considere más importante. Limite la discusión a un máximo de 3 minutos. No es crítico ser 100% exacto.

Ahora dibuje un lienzo de contexto acotado y siga estos pasos para completar los detalles. Recomiendo usar 1 hoja de rotafolio o papel del mismo tamaño.
Después de completar estos pasos, repita el proceso hasta que haya identificado todos sus contextos limitados. Intente dividir su tiempo en partes iguales entre los candidatos identificados para el contexto acotado.

4.1 Definición del contexto general


Comience por definir el nombre de su contexto acotado y su descripción. La descripción debe mostrar el propósito del contexto en el dominio y su rol en el negocio, y no los detalles de implementación.

A continuación, debe hacer una clasificación estratégica. ¿Es el contexto acotado la parte principal del sistema, un elemento auxiliar, uno común o algo más? Lea la publicación de Vlad si necesita ayuda para elegir.

imagen
Como ejemplo, un lienzo de contexto acotado lleno después de pasar por el primer paso.

Próximos pasos


Si no puede encontrar un nombre claro, o escribir una descripción coherente y precisa, o si sus términos para lenguaje ubicuo (UL) son ambiguos, considere esto como retroalimentación a su diseño. Considere rediseñar los bordes o tome nota y regrese más tarde (generalmente es mejor volver más tarde).

4.2 Aclaración de las normas comerciales y la formación de un lenguaje común.


Ahora regrese a EventStorming y mire las notas para este contexto acotado. Encuentre las reglas y políticas comerciales más importantes, luego intente seleccionar las 3 más importantes y agregarlas al lienzo.
Konstantin Gustov en TechLead Conf 2020 hablará sobre sus muchos años de experiencia con Ubiquitous Language y otros componentes DDD en Raiffeisen.
Este también es un buen momento para buscar palabras o frases clave de negocios para agregarlas al lienzo en la sección Idioma ubicuo. Continuará agregando palabras y frases a lo largo del taller, ahora este es solo el punto de partida.

imagen

4.3 Análisis de características


El siguiente paso es explorar las posibilidades proporcionadas por el contexto acotado. Esto no solo aclara lo que está haciendo, sino que también ofrece muchos comentarios sobre el diseño. Puede hacer preguntas como:

  • ¿Está este contexto sobrecargado de responsabilidades?
  • ¿Las oportunidades parecen relacionadas?
  • ¿Las capacidades coinciden con el nombre y la descripción del contexto?
  • ¿Qué pasa si sacamos esta oportunidad de contexto?

Comience a definir oportunidades mediante la introducción de una interfaz pública. ¿Qué pueden solicitar los consumidores de este contexto acotado y qué comandos pueden invocar? Use flujos de datos de dominio para ver lo que los consumidores necesitan de este contexto limitado.

No todas las funciones se activan mediante comandos y solicitudes externas. Algunas funciones pueden iniciarse desde dentro. Por ejemplo, tareas programadas. A veces puede notar que las oportunidades están agrupadas, por ejemplo, un comando, una solicitud y una notificación. Si es así, póngalos juntos en el lienzo y asigne un nombre al clúster.

Puede tener la sensación de que la responsabilidad es inapropiada y debe relacionarse con otro contexto acotado. Si es así, selecciónelo con algún tipo de marca de identificación en la etiqueta.

imagen

Próximos pasos


Si le resulta difícil determinar las capacidades de contexto o siente que faltan algunas de ellas, le recomiendo volver a EventStorming y modelar este contexto limitado con más detalle con un enfoque en encontrar las capacidades necesarias para otros contextos o servicios.

Capacidades de profundización [opcional]


Diseñe todas las oportunidades en su lienzo para obtener características adicionales. Este detalle adicional lo ayudará a encontrar modelos alternativos. Si no hay suficiente espacio en el lienzo para las piezas, busque otra hoja de papel o espacio en la pared. Puede ir tantas capas más profundas como mejor le parezca.

4.4 Dependencias


Las dependencias son necesarias si queremos modularidad, pero también causan una amplia gama de problemas comerciales, técnicos y sociales. Por lo tanto, es importante ver las dependencias, comprender su influencia y considerar opciones alternativas. Por lo tanto, el último paso para diseñar un contexto acotado es asegurarse de capturar todas las dependencias clave de su contexto acotado.

Mirando a través de los diagramas de flujo de dominios y resultados de EventStorming, identifique cada dependencia que tenga un contexto acotado y escriba la siguiente información:

  • el nombre de otro contexto o servicio acotado;
  • Una breve explicación de por qué existe la adicción.
  • dónde está la dependencia: dentro de este sistema o en un sistema externo (por ejemplo, un servicio de terceros);
  • tipo de relación: esta es una dependencia entrante (otro servicio depende de este contexto limitado), saliente (este contexto limitado depende de otro), interfaz bidireccional o de usuario (la dependencia es algún tipo de interfaz de usuario).

Cuestione cada una de las dependencias: si es necesario, cuáles son los costos y beneficios de su disponibilidad. Si parece que puede prescindir de él, marque la dependencia con una etiqueta amarilla.

imagen

4.5 Crítica constructiva


Cuando haya completado el llenado del lienzo, tómese unos minutos para evaluar críticamente el diseño resultante de su contexto acotado. Divide tus comentarios en las siguientes categorías:

  • Bien : aspectos de diseño que te gustan.
  • Malo : aspectos de diseño que no te gustan.
  • Inseguro : aspectos de diseño de los que no está seguro.

4.6. Reflexión y repetición.


El buen diseño es iterativo. Antes de pasar al siguiente contexto acotado, retroceda y mire el panorama general. ¿Has aprendido algo que sea contrario a tu diseño? Si es así, tache los límites propuestos y luego continúe diseñando el siguiente contexto acotado.

En este punto, pregúntese si el dominio está modelado con suficiente detalle. ¿Fue difícil llenar algunas partes del lienzo? Si es así, intente otra ronda de EventStorming en todo el dominio o en algunas partes del mismo.

5. Crear mapas de contexto


Después de crear un lienzo para cada contexto acotado y recopilar comentarios de diseño, la siguiente parte de la sesión es un retorno a la exploración. Esta vez tiene un conjunto completo de conocimientos que lo ayudarán a encontrar las mejores opciones de diseño.

El resultado de este ejercicio es una colección de mapas de contexto básicos: visualizaciones de las relaciones estructurales entre contextos acotados y cualquier otro diagrama que considere necesario, como los diagramas de flujo de dominio. Cada equipo debe desarrollar al menos 3 mapas de contexto, cada uno de los cuales mostrará posibles opciones para construir el sistema.

imagen
Un ejemplo de un mapa de contexto muy preciso, para este taller es suficiente.

Realizaremos un mitap en TechLead Conf 2020, donde analizaremos las diversas técnicas, patrones y antipatrones de DDD y recopilaremos un radar visual. Que se publicará después de la conferencia.
La actividad final puede llevarse a cabo en forma libre. El objetivo es revisar la información recopilada y utilizarla para desarrollar una serie de diseños de sistemas. Como punto de partida, recomiendo:

  • Vea todas las revisiones recopiladas para cada contexto y experimente con revisiones “malas” e “inseguras”.
  • Haga preguntas de "qué pasa si" ...
  • "¿Qué pasa si transferimos esta oportunidad a otro contexto limitado?"
  • "¿Qué pasa si rompemos esta oportunidad y movemos una de las subfunciones a otro contexto acotado?"
  • "¿Qué pasa si dividimos el contexto acotado en varios contextos?"
  • "¿Qué pasa si aprovechamos una oportunidad de cada uno de estos tres contextos y la usamos en un nuevo contexto?"
  • "¿Qué pasa si duplicamos la funcionalidad para eliminar la adicción?"
  • "¿Qué pasa si creamos un servicio común para reducir la duplicación en diferentes contextos?"
  • "¿Qué pasa si aislamos oportunidades verdaderamente clave y trasladamos el resto a un lugar más pacífico, en un contexto separado?"

Si prefiere visualizar estas transformaciones, las siguientes ilustraciones pueden ser útiles:

imagen

imagen

imagen

Cierre del taller


Para completar la sesión, cada grupo debe presentar una selección de los mapas de contexto que crearon y discutir las compensaciones de cada diseño. Debe explicar su elección, para esto generalmente es suficiente una presentación de 5 a 10 minutos.

Lo que debe tener en cuenta en la presentación:

  • : .
  • : .
  • , , .

- TechLead Conf 8 9 . 32 , , , , DDD .

- — ( , ). , .

More articles:


All Articles