Diez imágenes explican claramente los seis problemas y los seis pasos del modelado ddd

Diez imágenes explican los seis problemas y pasos del modelado ddd de la siguiente manera:

1 Seis problemas

1.1 Por qué utilizar

El núcleo La principal característica de la metodología DDD es descomponer continuamente los problemas, descomponer los grandes problemas en pequeños problemas y dividir las grandes empresas en áreas pequeñas. En resumen, es dividirlos, conquistarlos y derrotarlos uno por uno.

Dividir y conquistar significa que no tenemos forma de tratar directamente con grandes empresas. Necesitamos descomponerlas de acuerdo con un método determinado y descomponerlas en áreas pequeñas con alta cohesión para que la empresa tenga límites claros. y somos capaces de manejar estas áreas pequeñas. Sí, este es el núcleo del diseño impulsado por dominios.

Cada avance significa que cuando el problema se divide en áreas pequeñas, debido a que las áreas pequeñas están cohesivas y sus subáreas están altamente relacionadas, podemos diseñarlas en detalle en la dimensión técnica y en la dimensión de gestión. Según Dominios divide el trabajo en proyectos. Cabe señalar que DDD no puede reemplazar el diseño detallado, DDD es para un diseño detallado más claro.

En la industria de Internet donde los microservicios son populares, cuando el negocio se vuelve cada vez más complejo, los técnicos necesitan resolver el problema de cómo dividir los límites de los microservicios. La característica de DDD de aclarar los límites comerciales se puede utilizar para resolver esto. problema.

1.2 Métodos y objetivos

Nuestro objetivo es dividir el negocio en límites claros, y DDD es uno de los métodos eficaces para lograrlo. Esto requiere una atención especial. DDD es un método, no un objetivo, y no es necesario utilizarlo por el simple hecho de usarlo.

Por ejemplo, las empresas cuyos modelos de negocio son relativamente simples y se pueden analizar fácilmente no necesitan usar DDD. También hay algunos proyectos cuyo objetivo es verificar rápidamente el proyecto, que es breve y rápido. Es posible que no sea necesario utilizar un diseño basado en dominios en la etapa inicial.

1.3 General y parcial

Un dominio se puede dividir en múltiples subdominios, y los subdominios se pueden dividir en múltiples subdominios. El contexto acotado es esencialmente un. una especie de subsubdominio, por lo que cuando se descompone el negocio, ¿un módulo de negocio es un dominio, un subdominio o un subsubdominio?

Creo que no es necesario insistir en este tema, porque depende de la perspectiva desde la que se mire este módulo. El todo que crees puede ser la parte de otra persona, y la parte que crees que puede ser el todo de otra persona, no importa el nombre. Lo más importante es reunir módulos altamente relacionados con el negocio de acuerdo con el principio de alto. cohesión.

1.4 Granularidad gruesa y fina

No existe un estándar unificado para la granularidad de la división comercial. Debe considerarse de manera integral en función de las necesidades comerciales, los recursos de desarrollo, la solidez técnica y otros factores. Por ejemplo, si los microservicios se dividen demasiado, aumentará la complejidad del desarrollo, la implementación y el mantenimiento.

Sin embargo, si la división es demasiado aproximada, puede provocar que una gran cantidad de empresas estén altamente acopladas. El desarrollo y la implementación son muy rápidos, pero faltan mantenibilidad y escalabilidad. la situación real.

1.5 Dominio y Datos

Una diferencia importante entre los objetos de dominio y los objetos de datos es el método de almacenamiento de los objetos de valor. Antes de analizar los objetos de dominio y los objetos de datos, primero analizamos el concepto de entidades y objetos de valor. Una entidad es un objeto con un identificador único, y el identificador único acompañará al objeto de la entidad durante todo su ciclo de vida y no se puede cambiar. Un objeto de valor es esencialmente una colección de atributos y no tiene un identificador único.

Los objetos de dominio contienen objetos de valor y al mismo tiempo conservan el significado comercial de los objetos de valor, mientras que los objetos de datos pueden usar una estructura más flexible para guardar objetos de valor, simplificando el diseño de la base de datos.

Suponiendo ahora que necesitamos gestionar la información de los jugadores de fútbol, ​​¿cómo deberían diseñarse el modelo de dominio y el modelo de datos correspondientes? El nombre, la altura y el peso son los atributos esenciales de un atleta y, junto con un número único, pueden corresponder a objetos de entidad. La distancia recorrida, la tasa de éxito en los pases y el número de goles marcados son el desempeño de los atletas en el juego. El conjunto de estos atributos puede corresponder a objetos de valor.

Los objetos de valor se pueden almacenar en estructuras de datos sueltas en objetos de datos, mientras que los objetos de valor deben conservar su significado comercial en objetos de dominio.

1.6 Abstracción y Flexibilidad

El núcleo de la abstracción es encontrar similitudes y extraer factores comunes para diferentes cosas. El núcleo de la implementación es encontrar diferencias y ampliar sus respectivos atributos y características. Por ejemplo, el patrón de diseño del método de plantilla utiliza la abstracción para construir el marco y la implementación para ampliar los detalles.

Volvamos a la discusión del modelo de datos y podemos encontrar que las secuencias de comandos son una forma de expandir la flexibilidad. Las secuencias de comandos no solo se refieren al uso de secuencias de comandos maravillosas y QLExpress para mejorar la flexibilidad del sistema, sino que también incluyen opciones ligeramente escalables. datos.

El modelo de datos abstrae atributos básicos como el nombre, la altura y el peso. Para los atributos de rendimiento del juego que cambian con frecuencia, estos valores de atributos pueden cambiar con frecuencia, e incluso los atributos mismos pueden cambiar con frecuencia. se puede agregar el número de disparos, el número de avances, etc., por lo que se utiliza una estructura de datos JSON flexible para el almacenamiento.

2 Seis pasos

La teoría de la ingeniería siempre debe implementarse, y la implementación también requiere algunos pasos y métodos. En este artículo, analizamos un sistema de gestión de información de jugadores de fútbol. El objetivo es gestionar toda la información de enlace de los atletas, desde la transferencia hasta los partidos. Es posible que nunca hayas estado expuesto a este sistema, así que analicémoslo juntos.

Cabe señalar que este ejemplo se centra en demostrar cómo implementar la metodología DDD y que los detalles comerciales pueden no ser completos.

2.1 Clasificación de procesos

Hay dos cuestiones a considerar a la hora de clasificar el proceso. La primera pregunta es ¿desde qué perspectiva debemos clasificar? Porque diferentes personas ven el proceso de manera diferente. La respuesta es que depende del problema que deba resolver el sistema, porque necesitamos administrar toda la información de enlace de los atletas desde la transferencia hasta el juego, por lo que comenzar desde la perspectiva del atleta es una opción adecuada.

La segunda pregunta es ¿qué debo hacer si no estoy familiarizado con el negocio? Como no somos expertos en deportes y ejercicio, no conocemos los detalles comerciales de todo el enlace.

La respuesta es que los expertos en negocios deben estar presentes al ordenar el proceso, porque sin detalles reales del negocio, el diseño basado en dominios es imposible. De manera similar, al clasificar procesos comerciales complejos en Internet, deben participar gerentes de producto u operaciones que estén familiarizados con el negocio en cuestión.

Supongamos que los expertos en negocios del fútbol han resuelto el proceso comercial, el deportista propone una transferencia y, una vez alcanzado el consenso, acude al nuevo club para un examen físico. Si se aprueba el examen físico, el. se firmará el contrato. Después de ingresar al nuevo club, entrenar, jugar el partido después de cumplir con los indicadores de entrenamiento y asistir a la conferencia de prensa después del partido.

2.2 Modelado de cuatro colores

(1) Objeto de escala de tiempo

El primer color del modelado de cuatro colores es el rojo, que representa el objeto de escala de tiempo. El objeto de marca de tiempo es el objeto más importante en el modelado de cuatro colores y puede entenderse como un documento comercial central. Durante el proceso comercial, se deben dejar documentos para las empresas clave. A través de estos documentos se puede rastrear todo el proceso comercial.

El objeto de escala de tiempo tiene dos características: primero, es la inmutabilidad de los hechos, que registra los hechos que ocurrieron en un determinado momento o período de tiempo en el pasado. El segundo es la trazabilidad de la responsabilidad, que registra la información que preocupa a los directivos. Ahora analizamos qué objetos de marca de tiempo se incluyen en este sistema y qué documentos comerciales centrales deben dejarse atrás.

Los traslados corresponden a documentos de transferencia, los exámenes físicos corresponden a documentos de examen físico, los contratos firmados corresponden a documentos de contrato, la capacitación corresponde a documentos indicadores de capacitación, los partidos corresponden a documentos indicadores de partido y las conferencias de prensa corresponden a documentos de entrevista. Con base en el análisis, se dibujan los siguientes objetos de escala de tiempo:

(2) Participantes, lugares y objetos

Estos tres tipos de objetos están representados por el verde en los cuatro colores. modelado Usamos el escenario de comercio electrónico. Tome un ejemplo para ilustrar. Cuando un usuario paga para comprar productos de un comerciante, el usuario y el comerciante son participantes. Cuando el sistema logístico entrega mercancías, el documento de entrega debe tener un objeto de dirección de entrega, y el objeto de dirección es el lugar. Los pedidos requieren objetos de producto, la logística y la distribución requieren bienes, y los bienes y bienes son objetos.

Analizamos este ejemplo y descubrimos que los "participantes" incluyen gerentes generales, médicos del equipo, entrenadores, fanáticos y reporteros, los "lugares" incluyen direcciones de entrenamiento, direcciones de juegos y direcciones de entrevistas, y "cosas" incluyen camisetas firmadas y balones de fútbol firmados.

(3) Objetos de rol

Indicados en amarillo en el modelado de cuatro colores, este tipo de objeto indica el rol de los participantes, lugares y objetos en el proceso de negocio.

(4) Describir el objeto

Agregue información de descripción relacionada con el objeto, que está representado por azul en el método de modelado de cuatro colores.

2.3 División de Dominios

Durante el proceso de modelado de cuatro colores, nos dimos cuenta de que el objeto de marca de tiempo es el objeto más importante porque contiene los documentos centrales del sistema empresarial. Al dividir campos, también somos inseparables de los objetos de escala de tiempo. El núcleo es dividir los campos comerciales mediante la convergencia de objetos de escala de tiempo relacionados.

2.4 Eventos de dominio

Cuando algo sucede en el sistema empresarial, si hay acciones de seguimiento en este dominio u otros campos, entonces llamamos a este evento un evento de dominio necesario. para ser percibido.

Por ejemplo, si un jugador se lesiona durante un juego, este es un evento del subdominio del juego, pero los subdominios médico y de entrenamiento deben estar al tanto de ello. Luego, el subdominio del juego enviará un evento y. los subdominios médico y de formación se suscribirán.

Por ejemplo, si un jugador marca un gol en un juego, este también es un evento del subdominio del juego, pero los subdominios de entrenamiento y contrato también prestarán atención a este evento. Luego, el subdominio del juego también enviará. un evento, y los subdominios de formación y contrato se suscribirán a él.

Existe un problema que debe tenerse en cuenta a través de la interacción de eventos. La implementación empresarial a través de la suscripción a eventos solo puede adoptar una coherencia final, y es necesario abandonar una coherencia fuerte, lo que puede introducir una nueva complejidad que requiera compensaciones.

2.5 Construcción del proyecto

(1) API

Capa de interfaz: proporciona declaraciones de interfaz externa y objetos DTO

(2) controlador

Capa de acceso: Proporciona entrada de acceso HTTP

(3) servicio

Capa empresarial: Tanto la capa de dominio como la capa empresarial incluyen servicios, pero para diferentes propósitos. La capa empresarial puede combinar negocios en diferentes campos y puede agregar aspectos de control de flujo, monitoreo, registro y control de permisos. Es más rica que la capa de dominio y proporciona objetos BO

(4) dominio

Capa de dominio: Proporciona DMO (DomainObject), VO, eventos y objetos de acceso a datos. El núcleo es la subcontratación según el dominio. Alta cohesión dentro del dominio y bajo acoplamiento entre dominios.

(5. ) dependencia

Capa de acceso externo: en este módulo, se llaman servicios RPC externos y se analizan los códigos de retorno y los datos

(6) infraestructura

Capa básica : Contiene funciones básicas, como herramientas de almacenamiento en caché, colas de mensajes, bloqueos distribuidos, envío de mensajes y otras funciones.

Ampliamos la capa de campo de análisis. El núcleo es subcontratar según el campo y proporcionar DMO, VO,. eventos, objetos de acceso a datos, servicios de alto nivel en el campo. Cohesión y bajo acoplamiento entre dominios. Por ejemplo, el dominio1 corresponde al subdominio de contrato y el dominio2 corresponde al subdominio de capacitación.

2.6 Diseño Detallado

Hasta ahora, las áreas han sido determinadas. Ahora las tareas se pueden dividir. Los miembros del grupo son responsables de una o más áreas para el diseño detallado. Todos conocen los diagramas de casos de uso, los diagramas de actividades, los diagramas de secuencia, el diseño de bases de datos y el diseño de interfaces. Cabe señalar que el diseño basado en dominios no reemplaza el diseño detallado, sino que proporciona un diseño detallado más claro.

3 Resumen del artículo

Este artículo analiza seis cuestiones a las que se debe prestar atención al implementar DDD y analiza los seis pasos de la implementación a través de un caso de sistema de gestión de información de jugadores de fútbol. En las aplicaciones reales, cada forma de negocio puede ser muy diferente, pero la metodología puede ser universal. Debemos dejar en claro que el núcleo de DDD es dividir y conquistar y utilizar algunos métodos probados y efectivos para modelar. será de ayuda para todos.

————————————————

Declaración de derechos de autor: este artículo es un artículo original del blogger de CSDN "JAVA Frontline" y sigue CC 4.0 Acuerdo de derechos de autor BY -SA, adjunte el enlace de la fuente original y esta declaración al reimprimir.