Tabla de contenido
¿Qué necesitas para prepararte para tormentas de eventos?
1. Participantes en la tormenta del evento.
2. Materiales para prepararse ante una tormenta de eventos
3. El lugar del evento tormenta ¿Qué tipo de lugar es adecuado para el evento tormenta?
4. Enfoque del análisis de eventos de tormentas
¿Cómo construir un modelo de dominio con Event Storm?
2. Análisis de escenarios empresariales
4. División y diseño de microservicios.
¿Recuerda por qué se eligió DDD para el diseño de microservicios?
Una de las razones más importantes es que el modelo de dominio establecido por el método DDD puede dividir claramente los límites lógicos y físicos de los microservicios. Se puede decir que en la práctica de DDD, un buen modelo de dominio está directamente relacionado con el nivel de diseño de los microservicios. Por tanto, creo que el diseño estratégico de DDD es más importante que el diseño táctico, es por ello que nuestro contenido se centrará más en el diseño estratégico.
Entonces, ¿qué método deberíamos adoptar para analizar y construir un modelo de dominio a partir del intrincado dominio empresarial?
Es la tormenta de eventos que he mencionado muchas veces antes. La tormenta de eventos es una actividad de equipo. Los expertos en el dominio y los equipos de proyecto enumeran todos los eventos del dominio en el dominio mediante una lluvia de ideas. Después de la integración, se forma la colección final de eventos del dominio y marcan el rol del iniciador del comando para cada evento. Los comandos pueden ser iniciados por los usuarios o activados por llamadas al sistema o temporizadores de terceros, etc. Finalmente, se clasifican los eventos y se clasifican las entidades, los agregados, las raíces agregadas y los contextos acotados.
Event Storm es un método que se utiliza a menudo en el diseño de estrategias DDD y que puede analizar y descomponer rápidamente dominios comerciales complejos y completar el modelado de dominios. Entonces, ¿cómo funcionan exactamente las tormentas de eventos? ¿Qué necesitas para prepararte con anticipación para eventos de tormentas? ¿Y cómo utilizar Event Storm para crear un modelo de dominio? Hoy nos centraremos en resolver estos problemas y obtener una comprensión profunda de todo el proceso de las tormentas de eventos.
¿Qué necesitas para prepararte para tormentas de eventos?
1. Participantes en la tormenta del evento.
Event Storm adopta un enfoque de taller, reuniendo a equipos de proyecto y expertos en el dominio, y diseñando el modelo de dominio paso a paso de una manera visual y altamente interactiva. Los expertos en dominios son actores centrales esenciales en las tormentas de eventos. Es posible que muchas empresas no tengan esta función, entonces, ¿qué tipo de personas deberíamos buscar para actuar como expertos en el dominio?
Los expertos en el dominio son expertos en la materia con conocimientos profundos sobre el negocio o el dominio del problema. Tienen una buena comprensión de cómo se realizan el negocio y el sistema, y también tienen un profundo conocimiento de por qué están diseñados de esta manera. Si en su empresa no existe ese puesto, no importa, puede elegir al candidato adecuado según este estándar entre personal comercial, analistas de demanda, gerentes de producto o desarrolladores con muchos años de experiencia en este campo.
Además de los expertos en el dominio, otros participantes en el evento pueden ser miembros del equipo del proyecto, como expertos en DDD, arquitectos, gerentes de producto, gerentes de proyecto, desarrolladores y evaluadores. cuello
El modelado de dominio es el proceso de unificar el lenguaje del equipo, por lo que el equipo del proyecto debe participar en el modelado de dominio lo antes posible para establecer de manera eficiente un lenguaje común para el equipo. Cuando se trata de la construcción de microservicios, el modelo de dominio también es más fácil de mantener coherente con la arquitectura del sistema.
2. Materiales para prepararse ante una tormenta de eventos
Los participantes en el evento Storm escribirán sus pensamientos y opiniones en notas adhesivas y pegarán las pegatinas en los lugares correspondientes de la pared. A este proceso lo llamamos en broma "pintar la pared". Así que los post-it y los bolígrafos son materiales imprescindibles, además, también puedes preparar alguna cinta o botones magnéticos para que las pegatinas puedan ser sustituidas en cualquier momento.
Vale la pena recordar que en este proceso necesitamos usar pegatinas de diferentes colores para distinguir los comportamientos del dominio. Como se muestra en la siguiente figura, podemos usar azul para representar comandos, verde para representar entidades, naranja para representar eventos de dominio y amarillo para representar información complementaria. La información complementaria se utiliza principalmente para explicar precauciones, como las dependencias externas. El color no es fijo, es sólo mi costumbre y la unidad dentro del equipo es la clave.
3. El lugar del evento tormenta ¿Qué tipo de lugar es adecuado para el evento tormenta?
¿Necesita preparar salas de reuniones, proyecciones y sillas tal como organiza una reunión? ¡Nada de esto es necesario! Todo lo que necesitas es una pared lo suficientemente larga y un espacio lo suficientemente grande. Las paredes son para pegatinas y el gran espacio permite que las personas se muevan y colaboren fácilmente. Elimine la tormenta de mesas y sillas del evento y verá que los participantes son más productivos.
El inventor de Event Storm sugirió una vez que se debería preparar una pared de ocho metros de largo para que el diseño no estuviera limitado por el espacio. Por supuesto, esto no es una condición necesaria, depende de las condiciones reales de cada persona, pero no dejes que tu pensamiento se limite.
4. Enfoque del análisis de eventos de tormentas
En el proceso de modelado de dominios, debemos centrarnos en el lenguaje y el comportamiento de este tipo de negocio. Por ejemplo, ¿ciertas acciones o comportamientos (eventos) empresariales desencadenarán la siguiente acción empresarial y cuáles son las entradas y salidas de esta acción (evento)? Quién (entidad) emitió qué acción (comando) y desencadenó esta acción (evento)... Podemos analizar objetos de dominio como eventos, comandos y entidades en el modelo de dominio a partir de este vocabulario oculto.
¿Cómo construir un modelo de dominio con Event Storm?
El proceso de modelado de dominio incluye principalmente varias etapas importantes: visión del producto, análisis de escenarios comerciales, modelado de dominio y división y diseño de microservicios. Permítanme tomar el centro de usuarios como ejemplo para presentarles cómo utilizar Event Storm para crear un modelo de dominio.
1. Visión del producto
El objetivo principal de la visión del producto es diseñar el valor de nivel superior del producto, a fin de llegar a un consenso sobre información como los usuarios objetivo del producto, los valores fundamentales y los puntos de competencia diferenciados, a fin de evitar que el producto se desvíe de la dirección.
Roles participantes en la visión del producto: expertos en el dominio, requisitos comerciales, gerentes de producto, gerentes de proyecto y gerentes de desarrollo.
Antes de modelar, el equipo del proyecto debe considerar los dos puntos siguientes:
- ¿Qué puede hacer el centro de usuarios?
- ¿Cuáles son las diferencias y ventajas entre su alcance comercial, usuarios objetivo, valor central y visión, y otros productos similares?
Este proceso también es un proceso para aclarar la dirección de la construcción del centro de usuarios y unificar el pensamiento del equipo. Los participantes deben expresar sus opiniones sobre cada punto (el contenido de la columna más a la izquierda en la figura siguiente), escribir en la pegatina con un bolígrafo de agua y pegarlo en la posición de la pegatina amarilla. Este proceso permitirá a los participantes expresar plenamente sus opiniones y, finalmente, las opiniones divergentes se unificarán en un lenguaje común y se establecerá el muro de visión del producto como se muestra a continuación. Si la visión del producto y los objetivos de su equipo ya están claros, puede ignorar este paso.
2. Análisis de escenarios empresariales
El análisis de escenarios comienza desde la perspectiva del usuario. Basado en procesos de negocios o viajes de usuario, el análisis de escenarios y casos de uso se utiliza para explorar escenarios típicos en el dominio, descubrir objetos de dominio como eventos, entidades y comandos de dominio, y respaldar el modelado de dominio. Los participantes de Event Storm deben revisar todos los detalles comerciales tanto como sea posible, expresar plenamente sus opiniones y no perderse los puntos comerciales.
Roles participantes en el análisis de escenarios: expertos en el dominio, gerentes de productos, analistas de requisitos, arquitectos, gerentes de proyectos, gerentes de desarrollo y gerentes de pruebas.
Hay tres escenarios comerciales típicos en el centro de usuarios:
- El primero es la configuración del sistema y del trabajo, configurando los permisos del menú de los trabajos en el sistema;
- El segundo es la configuración de permisos de usuario, que establece cuentas y contraseñas para los usuarios y establece posiciones de usuario;
- El tercero es el sistema de inicio de sesión del usuario y la verificación de permisos, que genera registros de operación y inicio de sesión del usuario.
De acuerdo con el proceso comercial, podemos buscar eventos de campo clave en el proceso comercial del usuario paso a paso, como eventos como la creación de empleo y la creación de usuarios. Luego averigüe qué comportamientos causarán estos eventos de dominio. Estos comportamientos pueden generarse mediante una combinación de uno o varios comandos. Por ejemplo, al crear un usuario, el primer comando es obtener información del usuario del sistema de recursos humanos de la empresa y el segundo. El comando es Crear un usuario en el centro de usuarios según la información del empleado de RR.HH. Una vez creado el usuario, se generará el evento de dominio que el usuario ha creado. Por supuesto, este evento de campo puede desencadenar el siguiente paso, como publicar en el sistema de correo electrónico para notificar al usuario que se ha creado, pero puede terminar aquí y es necesario analizar si hay algún siguiente paso de acuerdo con el evento específico. situación.
Durante el análisis de la escena, se generarán muchos comandos y eventos de dominio. Utilizo el azul para representar comandos, el naranja para representar eventos de dominio y el amarillo para representar información complementaria, como la descripción de que los datos de información del usuario provienen del sistema de recursos humanos.
3. Modelado de dominio
Al modelar dominios, descubriremos las entidades que generan comandos en función de los objetos de dominio generados durante el proceso de análisis de la escena, como comandos, eventos, etc., y analizaremos las dependencias entre entidades para formar agregados y delinearemos el contexto delimitado para los agregados Establecer modelos de dominio y dependencias entre modelos. El modelo de dominio puede guiar el diseño de microservicios hacia arriba mediante el uso del contexto acotado, y el diseño de raíces, entidades y objetos de valor agregados puede guiarse hacia abajo mediante la agregación.
Roles participantes en el modelado de dominios: expertos en el dominio, gerentes de productos, analistas de requisitos, arquitectos, gerentes de proyectos, gerentes de desarrollo y gerentes de pruebas.
En concreto, se puede dividir en tres pasos.
Paso 1: Extraiga las entidades que generan estos comportamientos a partir de comandos y eventos. Las entidades están representadas por pegatinas verdes. Al analizar los datos de comportamiento, como comandos y eventos en el centro de usuarios, extrajimos siete entidades que generaron estos comportamientos: usuarios, cuentas, tickets de autenticación, sistemas, menús, posiciones y registros de usuarios.
Paso 2: Encuentre la raíz agregada de las siete entidades de acuerdo con las propiedades de administración de la raíz agregada. Por ejemplo, el usuario administra entidades relacionadas con el usuario y objetos de valor, y el sistema puede administrar entidades como menús relacionados con el sistema, etc. ., y puede encontrar usuarios y sistemas, etc. raíz agregada. Luego, de acuerdo con los principios de dependencia empresarial y cohesión empresarial, la raíz agregada y sus entidades asociadas y objetos de valor se combinan en agregados. Por ejemplo, las entidades del sistema y del menú se pueden combinar en agregados de "funciones del sistema". Según el método anterior, el centro de usuarios tiene seis agregaciones de funciones del sistema, posiciones, información de usuario, registros de usuario, cuentas y tickets de autenticación.
Paso 3: definir el contexto acotado y clasificar los agregados según la semántica del contexto. Según el contexto del dominio del usuario, las dos agregaciones de información básica del usuario e información de registro del usuario juntas constituyen el dominio de información del usuario, que gestiona la información básica del usuario, el inicio de sesión del usuario y los registros de operaciones, respectivamente. Las dos agregaciones de ticket de autenticación y cuenta juntas constituyen el dominio de autenticación, que implementa diferentes formas de inicio de sesión y autenticación, respectivamente. Los dos agregados de función y posición del sistema juntos constituyen el dominio de autoridad, que realiza respectivamente la gestión del sistema y del menú y la configuración de la posición del sistema. Según los límites comerciales, podemos dividir el centro de usuarios en tres contextos delimitados: información del usuario, autenticación y permisos.
4. División y diseño de microservicios.
Como se mencionó en el artículo anterior, en principio, un modelo de dominio se puede diseñar como un microservicio, pero debido a que solo se consideran factores comerciales en el modelado de dominio, los factores no comerciales como la tecnología, el equipo y el entorno operativo cuando se implementan los microservicios no se tienen en cuenta. Por lo tanto, al dividir y diseñar microservicios, no podemos simplemente usar el modelo de dominio como el único criterio para dividir microservicios, solo puede usarse como una base importante para dividir microservicios.
El diseño de microservicios también debe considerar la granularidad, las capas, la división de límites, la dependencia y la integración de los servicios. Además de considerar la responsabilidad empresarial única, también debemos considerar la separación de negocios sensibles y estables, requisitos no funcionales (como requisitos de escalamiento elástico, requisitos de seguridad, etc.), organización del equipo y eficiencia de la comunicación, tamaño del paquete de software, y la heterogeneidad técnica y otros factores no comerciales.
Roles sugeridos para el diseño de microservicios: expertos en dominios, gerentes de productos, analistas de requisitos, arquitectos, gerentes de proyectos, gerentes de desarrollo y gerentes de pruebas.
Si no se consideran los factores no comerciales en el diseño de microservicios del centro de usuarios, podemos diseñar completamente la relación uno a uno entre el modelo de dominio y los microservicios, y diseñar el centro de usuarios en tres microservicios: usuario, autenticación y autoridad. Sin embargo, si la cantidad de datos de registro de usuarios es enorme, tan grande que debe implementarse utilizando tecnología de big data, entonces la agregación de información de usuarios y la agregación de registros de usuarios tendrán heterogeneidad técnica. Aunque los colocamos en un modelo de dominio al modelar el dominio, si se considera la heterogeneidad tecnológica, estos dos agregados no son adecuados para ubicarse en el mismo microservicio. Podemos tomar la agregación como unidad de división, dividir la gestión de la información básica del usuario y la gestión del registro de usuarios en dos microservicios con tecnologías heterogéneas e implementarlos con diferentes tecnologías.
Resumir
Hoy hablamos sobre el método de diseño de Event Storm y cómo utilizar Event Storm para construir un modelo de dominio. Event Storm es un método diferente al análisis de requisitos y diseño de sistemas tradicionales. La mejor manera de aprender es encontrar algunos escenarios comerciales y hacerlo varias veces.
Según mi experiencia, en términos generales, para un proyecto de tamaño mediano, el tiempo de modelado de dominio es de aproximadamente dos semanas, que es básicamente el mismo que nuestro tiempo tradicional de análisis de demanda y diseño de sistema. Sin embargo, si todos los miembros del equipo participan en el proceso de modelado de dominio y establecen un lenguaje común antes del desarrollo del proyecto, esto será muy útil para el diseño y desarrollo de microservicios posteriores, y el costo de tiempo también se puede reducir según la situación.
De hecho, también aprendí que cuando muchos desarrolladores aprenden DDD por primera vez, no parece importarles mucho el modelado de dominio, sino que solo quieren aprender las ideas de diseño táctico de DDD, comenzar rápidamente y desarrollar microservicios.
Creo que esto es un malentendido de DDD, que se ha desviado de la idea de diseño central de DDD, es decir, antes de que podamos diseñar un límite de microservicio claro, debe haber un modelo de dominio con límites claros. Estas dos etapas son solo necesarias. y no podemos ser ignorados.