Microservicios y modelo de diseño basado en dominios DDD
¿Qué es el diseño basado en dominios DDD?
El primero en introducir el diseño impulsado por dominios se encuentra en el libro "Diseño impulsado por dominios: Soluciones complejas del núcleo del software" publicado por el programador Eric Evans en 2004. El diseño impulsado por dominios es la extensión y aplicación de conceptos de dominio. Y aplicarlo en el desarrollo de software. Su objetivo es conectar las partes relevantes del software al modelo en evolución, lo que facilita la creación de aplicaciones complejas.
Para casos de implementación de DDD, consulte el siguiente artículo:
"[Práctica del diseño basado en dominios en el desarrollo empresarial de Internet]
https://tech.meituan.com/2017/12/22/ddd-in-practice.html
"
Lo que necesita saber sobre DDD
Modelo de anemia
"Objetos en campo de anemia
Objeto de dominio anémico (Objeto de dominio anémico) se refiere a un objeto de dominio que solo se utiliza como portador de datos sin comportamiento ni acción.
"
En pocas palabras, es una entidad con solo métodos Getter / Setter. Dado que hay objetos en el dominio de la anemia, también hay objetos en el dominio de la congestión.
"Objetos de dominio de congestión
Además de los métodos Getter / Setter, las entidades también tienen métodos para describir el comportamiento y las acciones de la entidad.
"
Tomemos un ejemplo, aquí hay una entidad de pedido Order.
La entidad anterior no tiene un método para describir el comportamiento de la entidad, por lo que la entidad es un modelo de anemia.
Si necesitamos un método especial para modificar el pedido de entrega, podemos escribir así
¿Cómo se ve si escribe con un modelo de hiperemia?
Hemos agregado métodos para describir el comportamiento del estado del pedido buildDeliveryStatus().
El método de entrega del pedido se modifica para
Aquí llamamos directamente order.buildDeliveryStatus()para obtener el comportamiento del estado del envío, ocultando cómo se genera el comportamiento específico.
De hecho, según el pensamiento habitual, el modelo de anemia está bien, pero cuando la lógica empresarial se vuelve compleja, la lógica empresarial y el estado se dispersarán en una gran cantidad de métodos, y la intención del código original se volverá poco clara gradualmente.
"Creo que los desarrolladores que usan el modelo de congestión no necesitan preocuparse por los detalles específicos del comportamiento, solo necesitan usar este comportamiento, que se ajusta a los principios de diseño del empaquetado orientado a objetos.
"
Raíz agregada
Agregado es una colección de objetos relacionados a los que accede el mundo exterior en su conjunto. La raíz agregada es el nodo raíz de esta agregación.
entidad
Cuando un objeto se distingue por su identidad (en lugar de atributos), dicho objeto se denomina Entidad.
Objeto de valor
Cuando un objeto se utiliza para describir una transacción sin un identificador único, se denomina Objeto de valor.
Raíz agregada
Por qué los microservicios necesitan un diseño basado en dominios DDD
"Arquitectura de microservicios y patrones de diseño" escribió en el segundo capítulo de la estrategia de división de servicios que cuando dividimos un solo servicio en microservicios, podemos seguir los siguientes métodos de división:
""
Dividido por capacidad empresarial
Dividir por modo de subdominio
En este artículo, no discutiremos qué son los microservicios. Si no comprende los zapatos de los niños de los microservicios, puede leer este libro.
En el desarrollo de software a gran escala, es muy difícil para todos los equipos de la organización ponerse de acuerdo sobre un único modelo global y terminología. Algunos equipos de la organización pueden usar la misma terminología para diferentes conceptos, y algunos equipos pueden apuntar al mismo concepto. Usando una terminología diferente, DDD puede evitar estos problemas definiendo múltiples modelos de dominio, cada uno de los cuales tiene su propio alcance claro.
Antes de dividir los servicios, primero debemos crear un modelo de dominio abstracto. Cada servicio tiene su propio modelo de dominio. El modelo de dominio abstracto ayuda en la fase de división de servicios. Define algunas palabras que describen el comportamiento del sistema operativo. .
Modelo de dominio
La figura anterior es un diagrama esquemático del modelo de dominio en la etapa inicial del desarrollo del sistema.
La división por modo de subdominio adopta la idea de un diseño controlado por dominio DDD. El diseño dirigido por dominios es una metodología muy eficaz para crear software complejo. En el diseño impulsado por dominios, el modelo de dominio es el núcleo, y el diseño impulsado por dominios tiene dos conceptos importantes: subdominio y contexto limitado.
Una parte del dominio es el subdominio y el límite del dominio es el contexto acotado.
Contexto limitado
Como se muestra en la figura anterior, la línea discontinua elíptica indica el contexto delimitado y la línea discontinua encierra el subdominio. Cada subdominio asigna un modelo de dominio.
"Los conceptos de subdominios y contextos delimitados en DDD encajan bien con los servicios en la arquitectura de microservicios. El equipo autónomo en la arquitectura de microservicios es responsable del desarrollo del concepto y cada modelo de dominio en DDD es desarrollado por un equipo independiente. El concepto es coherente.
"
Arquitectura en capas de diseño basado en dominios
La arquitectura tradicional es la arquitectura de tres niveles.
""
Capa de presentación (capa de controlador): contiene el código que implementa la interfaz de usuario o API externa
Capa de lógica empresarial (capa de servicio): contiene lógica empresarial
Capa de persistencia de datos (capa Dao): darse cuenta de la lógica de interacción con la base de datos
Esta arquitectura en capas representa incorrectamente las dependencias de una aplicación bien diseñada. La lógica empresarial normalmente define la interfaz del método de acceso a los datos (lógica de adición, eliminación, modificación y consulta). La capa de persistencia de datos define la clase Dao que implementa la interfaz de la base de datos. Esta dependencia es lo contrario de lo que describe la arquitectura en capas.
Arquitectura en capas en el modelo impulsado por dominios
Estratificación de dominio
-
Interfaz de usuario: capa de interfaz de usuario: controlador, llamada de interfaz tranquila o interfaz de interfaz de usuario web, interfaz de interfaz de usuario móvil, servicios de terceros, etc .;
-
Capa de aplicación-aplicación: proporciona varias funciones de aplicación para la capa de presentación externamente y llama a la capa de dominio (servicio de dominio) internamente. La capa de aplicación es más como una estrategia para implementar un escenario específico u orquestación de procesos. Coopera con servicios en múltiples campos para realizar el aislamiento de escenarios y negocios;
-
Capa de dominio-dominio: responsable de expresar conceptos comerciales, comportamientos comerciales, estados comerciales y reglas comerciales. El modelo de dominio se encuentra en esta capa y es el núcleo del software comercial. Lo que proporciona es una serie de servicios atómicos Proporcionar una API OPEN rica en esta capa es un paso crucial para lograr la creación de componentes;
-
Capa básica de infraestructura: descubra la capa de aislamiento de negocios y tecnología. Generalmente incluyen: comunicación de red, persistencia de la base de datos, servicio de mensajes asincrónicos, servicio de puerta de enlace hacia el sur, etc. Cuando se lanza esta capa, se pueden implementar varios adaptadores para que sean compatibles con entornos de middleware heterogéneos internos, externos y de múltiples nubes.
Pensando en estas capas
En un programa orientado a objetos, la interfaz de usuario, la base de datos y otro código de soporte a menudo se escriben directamente en el objeto comercial. La lógica empresarial adicional está incorporada en el comportamiento de los componentes de la interfaz de usuario y los scripts de la base de datos. Algunas de las razones de esto es que facilita que las cosas funcionen rápidamente.
Sin embargo, cuando el código relacionado con el dominio se mezcla con otras capas, resulta extremadamente difícil leerlo y pensar en él. A primera vista, parece una modificación de la interfaz de usuario, pero se ha convertido en una modificación de la lógica empresarial. Los cambios en las reglas comerciales pueden requerir un seguimiento cuidadoso del código de la capa de la interfaz de usuario, el código de la base de datos y otros elementos del programa. Las implementaciones se unen y los objetos controlados por modelos ya no son factibles. También es difícil utilizar pruebas automatizadas. Por la tecnología y la lógica involucradas en cada actividad, el programa debe mantenerse simple, de lo contrario será difícil de entender.
Por lo tanto, necesitamos dividir correctamente una aplicación compleja en capas, desarrollar el diseño cohesivo en cada capa, concentrar el código relacionado con el modelo de dominio en su propia capa y separarlo de la interfaz de usuario, la aplicación y el código de infraestructura. Aislar.
Si el código no está claramente separado en una determinada capa, todo el código de secuencia de la capa de la aplicación aparecerá desordenado y será difícil de administrar. Una simple modificación del código en un lugar provocará peligros ocultos desconocidos para el código en otros lugares. La capa de dominio debe preocuparse por los problemas de la capa de dominio y no debe involucrar actividades de otras capas.
Modelo de dominio específico código en capas combate real
El nombre del paquete en el proyecto puede hacer referencia a la figura anterior.
Echemos un vistazo a cómo mi proyecto hace referencia al modelo de diseño basado en dominios DDD:
En primer lugar, he creado varios paquetes: application、controller、domain、infrastructure. El controllerpaquete aquí es en realidad la capa de interfaz de usuario.
solicitud
applicationPrincipalmente escribe algunos aspectos comerciales service.
dominio
domainLa parte principal es escribir algunos métodos para tratar con la base de datos (adiciones básicas, eliminaciones, cambios y verificación).
infraestructura
infrastructureEscriba principalmente algunas clases públicas, como clases de configuración configure, clases constantes constant, enumeraciones enumy clases de utilidad utils. Para usar otras capas.
Por último, se recomiendan dos libros para zapatos de niños interesados en DDD
"Diseño basado en dominios: la forma de lidiar con la complejidad central del software"
"Realización del diseño basado en dominios"
Recomendado en el pasado
-
¿Tiene miedo de las pérdidas de memoria cuando usa ThreadLocal?
-
Resumen de la entrevista de back-end de Java de 30.000 palabras (con PDF)
Escanee el código QR para ser más emocionante. O busque Lvshen_9 en WeChat , puede responder para obtener información en segundo plano
1.回复"java" 获取java电子书；
2.回复"python"获取python电子书；
3.回复"算法"获取算法电子书；
4.回复"大数据"获取大数据电子书；
5.回复"spring"获取SpringBoot的学习视频。
6.回复"面试"获取一线大厂面试资料
7.回复"进阶之路"获取Java进阶之路的思维导图
8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
9.回复"总结"获取Java后端面试经验总结PDF版
10.回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
11.回复"并发导图"获取Java并发编程思维导图（xmind终极版）Otro: haga clic en [ Mis beneficios ] para tener más sorpresas.