Para comprender mejor el proceso de diseño de DDD, este artículo utilizará un proyecto para llevarlo a comprender el diseño estratégico y el diseño táctico de DDD, recorrer todo el proceso desde el modelado de dominio hasta el diseño de microservicios y dominar el proceso de diseño principal de DDD juntos y puntos clave.
Información básica del proyecto.
El objetivo del proyecto es realizar la gestión de licencias y asistencia en línea. La descripción de la función es la siguiente:
- La persona que solicita la licencia completa el formulario de solicitud de licencia y lo presenta para su aprobación. Se verifica según la identidad de la persona que solicita la licencia, el tipo de licencia y el número de días de licencia. Según las reglas de aprobación, se presenta al superior para su aprobación paso a paso.
- De acuerdo con las reglas de asistencia, una vez que se cancelan los datos de licencia, se verifican los datos de asistencia y se generan las estadísticas de asistencia.
diseño estratégico
El diseño estratégico es el proceso de encontrar objetos de dominio y raíces agregadas basándose en el análisis del recorrido del usuario, agrupar entidades y objetos de valor para formar agregados, dividir contextos acotados y establecer modelos de dominio.
El método utilizado en el diseño estratégico es la tormenta de eventos, que incluye varios procesos principales, como la visión del producto, el análisis de escenarios, el modelado de dominios y la división de microservicios.
Participantes sugeridos en la fase de diseño estratégico: expertos en el dominio, demandantes de negocios, gerentes de productos, arquitectos, gerentes de proyectos, gerentes de desarrollo y gerentes de pruebas.
1. Visión del producto
La visión del producto es diseñar el valor de nivel superior del producto, llegar a un acuerdo sobre información como los usuarios objetivo del producto, los valores fundamentales y los puntos de competencia diferenciados, para evitar que el producto se desvíe de la dirección. Durante la tormenta del evento, todos los participantes escribieron sus opiniones en pegatinas para cada punto y las publicaron en la pizarra. El anfitrión del evento Storm discutirá cada pegatina y convergerá y unificará las opiniones divergentes para formar el siguiente mapa de visión del producto.
Recopilamos este mapa de visión del producto en un párrafo: para satisfacer las necesidades del personal interno y externo, sus licencias en línea, estadísticas de asistencia automática y gestión de personal externo, creamos este sistema de asistencia de licencias en línea, que es una plataforma de licencias en línea que puede automáticamente estadísticas de asistencia. Puede admitir redes internas y externas para solicitar licencias al mismo tiempo y administrar personal interno y externo para solicitar licencias y análisis de asistencia regular, a diferencia del sistema de recursos humanos, que solo administra personal interno y solo se puede utilizar en la intranet. Nuestros productos se pueden utilizar tanto en redes internas como externas, lo que permite una gestión sin diferencias del personal interno y externo.
A través del análisis de la visión del producto, el equipo del proyecto unificó el nombre del sistema: sistema de asistencia a licencias en línea, aclaró los objetivos del proyecto y las funciones clave, las diferencias clave con los productos de la competencia (RRHH) y sus propias ventajas y competitividad central.
El análisis de la visión del producto es muy valioso para los sistemas de nueva creación para aclarar el enfoque de la construcción del sistema, unificar los objetivos de formación de equipos y establecer un lenguaje común. Pero si los objetivos y requisitos de su sistema son muy claros, este paso puede ignorarse.
2. Análisis de escenarios
El análisis de escenarios consiste en explorar escenarios típicos en el dominio empresarial desde la perspectiva de los usuarios y generar la clasificación de escenarios que deben ser admitidos en el dominio, operaciones de casos de uso y dependencias entre diferentes subdominios para respaldar el modelado de dominio.
Juntos, los miembros del equipo del proyecto utilizan la tormenta de eventos para analizar el recorrido del usuario en cuanto a licencias y asistencia. De acuerdo con el recorrido y el análisis de escenarios de diferentes roles, clasifique todas las operaciones, comandos, eventos de dominio y dependencias externas desde las operaciones de front-end hasta la lógica empresarial de back-end de la manera más completa posible.
A continuación, tomaré como ejemplos los dos escenarios de solicitud de licencia y personal.
La primera escena: salir
Usuario: dejar persona
- Sistema de inicio de sesión de la persona que solicita la licencia: obtenga información de la persona que solicita la licencia y datos de permiso del microservicio de la autoridad, y complete la autenticación de inicio de sesión.
- Cree un formulario de licencia: abra la página de licencia, seleccione el tipo de licencia y la hora de inicio, e ingrese la información de la licencia. Guarde y cree un formulario de solicitud de licencia y envíe la solicitud de licencia para su aprobación.
- Modifique el formulario de licencia: consulte el formulario de licencia, abra la página de licencia, modifique el formulario de licencia y envíe la licencia para su aprobación.
- Enviar para aprobación: obtenga las reglas de aprobación, obtenga los aprobadores de la relación de organización de personal de acuerdo con las reglas de aprobación y asigne los aprobadores al formulario de licencia.
Segundo escenario: aprobación
Usuario: Aprobador
- Sistema de inicio de sesión del aprobador: obtenga información del aprobador y datos de autoridad de los microservicios de autoridad para completar la autenticación de inicio de sesión.
- Obtener formulario de solicitud de licencia: obtenga el formulario de solicitud de licencia con el nombre del aprobador, seleccione el formulario de solicitud de licencia.
- Aprobación: Complete los comentarios de aprobación.
- Aprobación nivel por nivel: si aún se requiere la aprobación de los superiores, de acuerdo con las reglas de aprobación, el aprobador se obtiene de la relación de organización de personal y el aprobador se asigna al formulario de licencia. Repita los 4 pasos anteriores.
- El último aprobador completa la aprobación.
Una vez completada la aprobación, se genera un evento en el campo Aprobación de licencia. Hay dos operaciones comerciales más en el seguimiento: enviar una notificación de que la solicitud de licencia ha sido aprobada y el sistema de correo electrónico de notificación notifica a la persona que solicita la licencia; enviar los datos de la solicitud de licencia a asistencia para su verificación.
La siguiente figura es el resultado del análisis de la escena de las relaciones entre la organización del personal y no se describirá el proceso de análisis detallado ni el análisis de la escena de asistencia.
3. Modelado de dominio
El modelado de dominio consiste en establecer un modelo de dominio mediante el análisis de dominios comerciales y problemáticos. Guíe el diseño de límites del microservicio hacia arriba a través del contexto delimitado y guíe el diseño del objeto de entidad hacia abajo a través de la agregación.
El modelado de dominio es un proceso convergente, dividido en tres pasos:
- El primer paso es encontrar objetos de dominio, como entidades de dominio y objetos de valor;
- El segundo paso es encontrar la raíz agregada y establecer un agregado de acuerdo con la relación de dependencia entre la entidad, el objeto de valor y la raíz agregada;
- El tercer paso es definir un contexto acotado basado en factores como los límites comerciales y semánticos.
Te lo explicamos en detalle paso a paso.
Paso 1: identificar objetos de dominio, como entidades y objetos de valor
Con base en el análisis de escenarios, analice y descubra las entidades y objetos de valor que inician o generan estos comandos o eventos de dominio, y recopile comandos y eventos relacionados con entidades u objetos de valor en entidades. La siguiente figura es la relación entre la entidad analizada y el comando. A través del análisis, encontramos entidades y objetos de valor como formularios de licencia, comentarios de aprobación, reglas de aprobación, personal, relaciones organizacionales, detalles de tarjetas de crédito, detalles de asistencia y estadísticas de asistencia.
Paso 2: definir agregación
Antes de definir un agregado, primero encuentre la raíz del agregado. De la entidad anterior, podemos encontrar dos raíces agregadas de "formulario de licencia" y "personal". Luego, descubra qué entidades y objetos de valor dependen estrechamente de la raíz agregada. Descubrimos que las opiniones de aprobación, las reglas de aprobación y los formularios de licencia están estrechamente relacionados, y las relaciones organizacionales están estrechamente relacionadas con el personal.
Después de conocer la relación entre estas entidades, encontramos que hay detalles de tarjetas de crédito, detalles de asistencia y estadísticas de asistencia, estas entidades no tienen una raíz agregada. A menudo encontrará este tipo de situaciones en el modelado de dominios, y debemos tratarlas de una manera especial para este tipo de escenario.
Las entidades de detalles de tarjetas de crédito, detalles de asistencia y estadísticas de asistencia son independientes entre sí y no se puede encontrar una raíz agregada. No son modelos de dominio ricos, pero completan la lógica comercial de asistencia en conjunto y tienen una alta cohesión comercial. Colocamos estas diversas entidades relacionadas con negocios en una sola agregación de asistencia. Al diseñar microservicios, todavía utilizamos el método de diseño y análisis DDD. Dado que no existe una raíz agregada para administrar entidades dentro de un agregado, podemos usar métodos tradicionales para administrar entidades.
Después del análisis, establecimos tres agregaciones de licencia, relación de organización del personal y asistencia. Entre ellos, la agregación de licencias tiene objetos de valor como formulario de licencia, entidad de opinión de aprobación y regla de aprobación. La relación personal-organización agrega entidades como las relaciones entre personal y organización. La agregación de asistencia tiene entidades como detalles de tarjetas de crédito, detalles de asistencia y estadísticas de asistencia.
Paso 3: definir el contexto acotado
Dado que la agregación de relaciones personal-organización y la agregación de solicitudes de licencia completan conjuntamente la función comercial de solicitar licencia, las dos están dentro del contexto acotado de solicitud de licencia. La agregación de asistencia por sí sola constituye el contexto acotado de las estadísticas de asistencia. Por lo tanto, dividimos el negocio en dos contextos acotados para las estadísticas de licencias y asistencia, y establecemos dos modelos de dominio para licencias y asistencias.
4. División de microservicios
En teoría, un contexto acotado se puede diseñar como un microservicio, pero es necesario considerar de manera integral una variedad de factores externos, como: unicidad de responsabilidad, separación de servicios sensibles y estables, requisitos no funcionales (como escalamiento elástico, lanzamiento de versiones). requisitos de frecuencia y seguridad), el tamaño del paquete de software, la eficiencia de la comunicación del equipo y la heterogeneidad técnica y otros factores no comerciales.
En este proyecto, dividimos los microservicios considerando principalmente el principio de responsabilidad única. Por lo tanto, según el contexto acotado, se puede dividir en dos microservicios: licencia y asistencia. Entre ellos, el microservicio de licencia incluye la relación de organización del personal y dos agregaciones de licencia, y el microservicio de asistencia incluye la agregación de asistencia.
En este punto, el diseño estratégico ha terminado. A través del diseño estratégico, establecimos un modelo de dominio y dividimos los límites de los microservicios. El siguiente paso es el diseño táctico, que es el diseño de microservicios. Tomemos el microservicio de licencia como ejemplo para explicar su proceso de diseño.
diseño táctico
El diseño táctico es el proceso de diseñar microservicios según el modelo de dominio. Esta etapa clasifica principalmente los objetos de dominio en el microservicio, clasifica la relación entre los objetos de dominio, determina sus posiciones en el modelo de código y la arquitectura en capas, establece la relación de mapeo entre el modelo de dominio y el modelo de microservicio, y las dependencias entre servicios.
Participantes sugeridos en la fase de diseño táctico: expertos en el dominio, gerentes de producto, arquitectos, gerentes de proyecto, gerentes de desarrollo y gerentes de pruebas.
El diseño táctico incluye las dos fases siguientes: analizar objetos de dominio de microservicio y diseñar la estructura del código de microservicio.
1. Analizar objetos de dominio de microservicio.
El modelo de dominio tiene muchos objetos de dominio, pero estos objetos tienen atributos comerciales relativamente pesados. Para completar la transición del modelo de dominio al microservicio, se necesitan más análisis y diseño. Con base en la tormenta de eventos, refinamos aún más los objetos de dominio y sus relaciones, y complementamos los detalles comerciales y técnicos que la tormenta de eventos puede pasar por alto.
¿Qué servicios debemos analizar en microservicios? ¿Superposición de servicios? ¿Qué servicios están compuestos y orquestados por servicios de aplicaciones? ¿Qué entidades y métodos de entidad incluyen los servicios de dominio? ¿Qué entidad es la raíz agregada? ¿Qué propiedades y métodos tiene una entidad? Qué objetos deberían diseñarse como objetos de valor, etc.
Identificación y diseño de servicios.
Los comandos de las tormentas de eventos son algunas operaciones externas y comportamientos comerciales, y también son las capacidades proporcionadas por los microservicios. A menudo corresponde a servicios de aplicaciones o servicios de dominio de microservicios. Podemos utilizar comandos como punto de partida para la identificación y el diseño de servicios. Los pasos específicos son los siguientes:
- Diseñar servicios de aplicaciones según comandos, determinar las funciones de los servicios de aplicaciones, recopilación de servicios, métodos de composición y orquestación. Los servicios de la colección de servicios incluyen servicios de dominio o servicios de aplicaciones de otros microservicios.
- Diseñar y definir servicios de dominio de acuerdo con los requisitos funcionales del servicio de la aplicación. Tenga en cuenta aquí: los servicios de aplicaciones pueden estar compuestos por múltiples servicios de dominio agregados.
- Según la función del servicio de dominio, determine las entidades y funciones en el servicio de dominio.
- Propiedades y métodos básicos de entidades de diseño.
Además, también debemos considerar el procesamiento asincrónico de eventos de dominio.
Tomo la acción de presentar para aprobación como ejemplo para ilustrar la identificación y el diseño de los servicios.
El proceso general de presentación para aprobación es:
- Según el tipo de licencia y la duración, consulte las reglas de aprobación de licencia para obtener el rol del próximo aprobador.
- Consulta al siguiente aprobador de la relación persona-organización según el rol de aprobación.
- Asigne un aprobador al formulario de licencia y guarde las reglas de aprobación en el formulario de licencia.
- A través del análisis, necesitamos diseñar los siguientes servicios y métodos en la capa de aplicación y la capa de dominio.
Capa de aplicación: envíe el servicio de aplicación para su aprobación.
Capa de dominio: los servicios de dominio incluyen la consulta de reglas de aprobación, la modificación de servicios de información del proceso de licencia y la consulta de servicios de aprobación de acuerdo con las reglas de aprobación, que se encuentran respectivamente en la agregación de relaciones de organización de personal y licencia. La entidad del formulario de licencia tiene un método para modificar la información del proceso de licencia y el objeto de valor de la regla de aprobación tiene un método para consultar las reglas de aprobación. La entidad persona tiene un método para consultar al aprobador de acuerdo con la regla de aprobación. La siguiente figura muestra los servicios que analizamos y las dependencias entre ellos.
Eso es todo para el proceso de identificación y diseño del servicio. Diseñemos los objetos en conjunto nuevamente.
objetos en conjunto
En la agregación de solicitudes de licencia, la raíz agregada es la solicitud de licencia. Después de la revisión de varios niveles del formulario de licencia, se generarán múltiples opiniones de aprobación. Para facilitar la consulta, podemos diseñar las opiniones de aprobación como entidades. Una vez aprobada la solicitud de licencia, se generará el evento de dominio de aprobación de la solicitud de licencia, por lo que también habrá una entidad de evento de solicitud de licencia. La agregación de licencias tiene las siguientes entidades: comentarios de aprobación (aprobadores de registro, estado de aprobación y comentarios de aprobación) y entidades de eventos de licencia.
Analicemos el objeto de valor de la agregación del formulario de licencia. Los datos de la persona que solicita la licencia y del siguiente aprobador provienen de la entidad de personal en la agregación de relaciones de organización de personal, que puede diseñarse como un objeto de valor. El tipo de personal, el tipo de licencia y el estado de aprobación son tipos de valor enumerados que pueden diseñarse como objetos de valor. Después de determinar las reglas de aprobación de licencia, las reglas de aprobación también se pueden utilizar como objeto de valor del formulario de licencia. La agregación de solicitudes de licencia contendrá los siguientes objetos de valor: solicitante de licencia, tipo de personal, tipo de licencia, próximo aprobador, estado de aprobación y regla de aprobación.
En resumen, podemos dibujar el diagrama de relación de objetos de agregación de licencias.
En la agregación de relaciones personal-organización, podemos establecer relaciones organizacionales entre el personal y encontrar líderes de aprobación superiores a través de tipos de relaciones organizacionales. Su raíz agregada es el personal, y las entidades tienen relaciones organizativas (incluidos tipos de relaciones organizativas y líderes de aprobación superiores), entre las cuales los tipos de relaciones organizativas (como gerentes de proyectos, jefes de división, gerentes generales, etc.) son objetos de valor. El líder de aprobación superior proviene de la raíz agregada del personal, que puede diseñarse como un objeto de valor. La agregación de la relación personal-organización contendrá los siguientes objetos de valor: tipo de relación de la organización, líder de aprobación superior.
En resumen, podemos dibujar nuevamente el diagrama de relaciones de objetos de agregación de relaciones de organización de personal.
Manifiesto de objeto dentro del microservicio
Después de determinar los atributos de cada objeto de dominio, podemos diseñar el objeto de código de cada objeto de dominio en el modelo de código (incluido el nombre del paquete, el nombre de la clase y el nombre del método del objeto de código) y establecer una relación de mapeo uno a uno. entre el objeto de dominio y el objeto de código. De acuerdo con esta relación de mapeo, el personal relevante puede localizar rápidamente la ubicación del código donde se encuentra la lógica empresarial. Después del análisis anterior, podemos analizar la lista de objetos en el microservicio como se muestra en la siguiente figura.
2. Diseñar la estructura del código de microservicio.
De acuerdo con el modelo de código de DDD y los paquetes, clases y métodos de objetos en cada dominio, podemos definir la estructura de código del microservicio saliente y diseñar los objetos de código.
Estructura del código de la capa de aplicación
La capa de aplicación incluye: servicios de aplicaciones, DTO y códigos relacionados con la publicación de eventos. Implemente servicios de aplicaciones relacionados con la agregación en la clase LeaveApplicationService y encapsule los servicios de aplicaciones para permisos y autenticación de microservicios externos en LoginApplicationService.
Aquí hay un recordatorio: si la lógica del servicio de aplicación es compleja, un servicio de aplicación puede crear una clase, lo que puede evitar que el código de una clase sea demasiado grande, lo que no favorece el mantenimiento.
Estructura del código de la capa de dominio
La capa de dominio incluye una o más clases de entidades agregadas, clases de entidades de eventos, servicios de dominio, fábricas y códigos relacionados con el almacén. Una agregación corresponde a un directorio de código de agregación, y las agregaciones están completamente aisladas en el código y se coordinan a través de la capa de aplicación.
La capa de dominio de microservicio de licencia contiene dos agregaciones de licencia y personal. Los códigos de personal y de licencia se colocan en paquetes de códigos en la estructura de directorios de sus respectivos agregados. Si a medida que el negocio se desarrolla, las funciones relacionadas con el personal deben separarse del microservicio de licencia, solo necesitamos modificar ligeramente el paquete de código de agregación de personal, implementarlo de forma independiente y lanzarlo rápidamente como un microservicio de personal. En este punto, los objetos de dominio, las capas y las dependencias de los microservicios están claramente ordenados. La arquitectura general y el modelo de código de los microservicios están básicamente completos.
trabajo de seguimiento
1. Diseño detallado
Después de completar el modelo de dominio y el diseño del microservicio, también debemos diseñar el microservicio en detalle. Se diseñan principalmente los siguientes contenidos: atributos de entidad, tablas y campos de bases de datos, mapeo entre entidades y tablas de bases de datos, especificación de parámetros de servicio y realización de funciones, etc.
2. Desarrollo y prueba de código.
Los desarrolladores solo necesitan encontrar la ubicación del código correspondiente a la función comercial de acuerdo con los documentos de diseño detallados y los requisitos funcionales, y completar el desarrollo del código. Una vez completado el desarrollo del código, los desarrolladores deben escribir casos de prueba unitaria y completar las pruebas de servicio basadas en los objetos dependientes de la simulación del deflector.
Resumir
Hoy hemos pasado por el proceso de diseño de DDD a través del proyecto de licencias y asistencias en línea.
El diseño estratégico de DDD comienza con tormentas de eventos, y luego necesitamos encontrar objetos de dominio como entidades, encontrar raíces agregadas para construir agregados, dividir contextos acotados y construir modelos de dominio.
El diseño táctico comienza con el comando de la tormenta de eventos, identifica y diseña servicios, establece las dependencias de los servicios en cada capa, diseña entidades y objetos de valor en microservicios, descubre todos los objetos de dominio en microservicios y establece la relación entre los objetos de dominio y el código. objetos Mapeo de relaciones.
De esta manera, el equipo del proyecto puede estar bien guiado en el desarrollo y prueba de microservicios.