En la arquitectura en capas DDD y el modelo de código de microservicio, colocamos capas de objetos de dominio de acuerdo con sus atributos y dependencias, y definimos los objetos de código correspondientes y la estructura del directorio de código. La arquitectura en capas determina la arquitectura general de los microservicios. Los objetos principales de los microservicios incluyen servicios y entidades, que trabajan juntos para completar la lógica empresarial.

¿Cómo colaboran estos servicios y entidades en cada capa de microservicios durante la operación? Hoy analizaremos el microservicio basado en la arquitectura en capas DDD para ver cómo se ve su estructura interna.

Colaboración de servicios.

1. Tipos de servicios

Comencemos revisando los servicios en una arquitectura en capas. Los microservicios diseñados según la arquitectura en capas incluyen servicios de fachada, servicios de aplicaciones, servicios de dominio y servicios básicos. Las principales funciones y responsabilidades de cada servicio de capa son las siguientes.

Servicio de fachada: ubicado en la capa de interfaz de usuario, incluida la interfaz y la implementación. Se utiliza para procesar la solicitud Restful enviada por el usuario y analizar el archivo de configuración ingresado por el usuario, etc., y pasar los datos a la capa de aplicación. O después de obtener los datos de la capa de aplicación, ensambla DO en DTO y transmite los datos a la aplicación de front-end.
Servicio de aplicación: ubicado en la capa de aplicación. Se utiliza para expresar el comportamiento de la aplicación y del usuario, es responsable de la combinación, orquestación y reenvío de servicios, es responsable de procesar la secuencia de ejecución de los casos de uso empresarial y el ensamblaje de resultados, y de proporcionar servicios de grano grueso externamente.
Servicio de dominio: ubicado en la capa de dominio. El servicio de dominio encapsula la lógica empresarial central y realiza la lógica del dominio central que requiere la cooperación de múltiples entidades. Combina u organiza la lógica empresarial de múltiples entidades o métodos, o encapsula métodos de entidad en una arquitectura en capas estricta y proporciona servicios de dominio para llamadas a la capa de aplicación.
Servicio básico: ubicado en la capa base. Proporcione servicios de recursos básicos (como bases de datos, caché, etc.), realice el desacoplamiento de cada capa y reduzca el impacto de los cambios de recursos externos en la lógica de las aplicaciones comerciales. Los servicios básicos son principalmente servicios de almacenamiento, que proporcionan servicios de recursos básicos mediante inversión de dependencia. Tanto los servicios de dominio como los servicios de aplicaciones pueden llamar a interfaces de servicios de almacenamiento para lograr la persistencia de los datos a través de los servicios de almacenamiento.

2. Llamada de servicio

Echemos un vistazo a la imagen de abajo. Las llamadas de servicio de microservicios incluyen tres escenarios principales: llamadas de servicio entre capas dentro de microservicios, llamadas de servicio entre microservicios y basadas en eventos de dominio.

Capa cruzada dentro del microservicio

La arquitectura de microservicios de llamadas de servicio a menudo adopta el patrón de diseño de separación de front-end y back-end, y las aplicaciones de front-end se implementan de forma independiente. La aplicación front-end llama al servicio Facade publicado en API Gateway y Facade se dirige al servicio de la aplicación. Como organización y orquestador de servicios, el servicio de aplicación tiene dos rutas para su invocación de servicio:

La primera es que los servicios de aplicaciones llaman y ensamblan servicios de dominio. En este punto, los servicios de dominio ensamblarán entidades y métodos de entidad para implementar la lógica central del dominio. El servicio de dominio obtiene el objeto de datos persistentes a través del servicio de almacenamiento y completa la inicialización de los datos de la entidad.
La segunda es que el servicio de la aplicación llama directamente al servicio de almacenamiento. Este método está dirigido principalmente a acceder a datos de capas básicas, como cachés y archivos. Este tipo de datos se utiliza principalmente para operaciones de consulta sin mucha lógica de dominio, no pasa por la capa de dominio y no involucra objetos persistentes de la base de datos.

Llamadas de servicio entre microservicios

Se puede acceder a los servicios de aplicaciones entre microservicios directamente o mediante una puerta de enlace API. Debido a las operaciones entre microservicios, al agregar y modificar datos, debe prestar atención a las transacciones distribuidas para garantizar la coherencia de los datos.

evento de dominio impulsado

El dominio impulsado por eventos incluye eventos dentro de microservicios y entre microservicios. El procesamiento asincrónico entre agregados se completa a través del bus de eventos (EventBus) en el microservicio. La comunicación entre microservicios se realiza a través de middleware de mensajes. El mecanismo controlado por eventos de dominio asíncrono es un método de acceso indirecto al servicio.

Una vez completado el procesamiento de la lógica empresarial del servicio de la aplicación, si se produce un evento de dominio, se puede llamar al servicio de publicación de eventos para completar la publicación del evento. Al recibir los datos del tema suscrito, el servicio de suscripción de eventos llamará al servicio de dominio de procesamiento de eventos para completar más operaciones comerciales.

3. Encapsulación y composición de servicios

Echemos un vistazo a la imagen de abajo. Los servicios de microservicio se encapsulan, componen y exponen desde la capa de dominio hacia arriba.

capa base

La forma de servicio de la capa básica son principalmente servicios de almacenamiento. El servicio de almacenamiento incluye interfaz e implementación. El servicio de interfaz de almacenamiento es llamado por la capa de aplicación o el servicio de capa de dominio, y el almacenamiento realiza el servicio y completa la persistencia o la inicialización de datos del objeto de dominio.

capa de dominio

La capa de dominio implementa la lógica empresarial central y es responsable de expresar los conceptos comerciales, el estado comercial y las reglas comerciales del modelo de dominio. Las principales formas de servicio son los métodos de entidad y los servicios de dominio.

La entidad adopta el modelo de hiperemia e implementa toda la lógica empresarial relacionada con la entidad dentro de la clase de entidad, y la forma de implementación es un método en la clase de entidad. Una entidad es la unidad de lógica empresarial atómica de un microservicio. Al diseñar, consideramos principalmente los atributos y el comportamiento comercial de la propia entidad y nos damos cuenta de las capacidades básicas centrales del modelo de dominio. No es necesario pensar demasiado en las operaciones externas y los procesos comerciales para garantizar la estabilidad del modelo de dominio.

DDD aboga por un modelo de dominio rico, en la medida de lo posible para atribuir lógica empresarial a objetos de entidad y diseñar las partes que no se pueden atribuir como servicios de dominio. Los servicios de dominio ensamblan y organizan múltiples entidades o métodos de entidad para implementar una lógica empresarial central compleja en múltiples entidades.

Para una arquitectura estrictamente en capas, si el método de una sola entidad necesita exponerse a la capa de aplicación, debe ser encapsulado por el servicio de dominio antes de que pueda exponerse al servicio de aplicación.

capa de aplicación

La capa de aplicación se utiliza para expresar el comportamiento de las aplicaciones y los usuarios, responsable de la combinación, orquestación y reenvío de servicios, el orden de ejecución de los casos de uso empresarial y el ensamblaje de resultados, la coordinación de servicios y datos entre diferentes agregados, y la liberación de eventos entre microservicios y suscripción.

Las funciones internas de los microservicios se exponen externamente a través de servicios de aplicaciones, de modo que se puede ocultar la complejidad de la lógica empresarial central de la capa de dominio y el mecanismo de implementación interna. Las principales formas de servicio de la capa de aplicación son: servicio de aplicación, publicación de eventos y servicio de suscripción.

Los servicios utilizados para la composición y orquestación en los servicios de aplicaciones se derivan principalmente de servicios de dominio y también pueden ser servicios de aplicaciones de microservicios externos. Además de completar la combinación y orquestación de servicios, dentro del servicio de aplicación también se pueden completar funciones como autenticación de seguridad, verificación de autoridad, verificación de datos preliminares y control de transacciones distribuidas.

Para lograr el desacoplamiento entre agregados en microservicios, las llamadas de servicio y las interacciones de datos entre agregados deben realizarse a través de servicios de aplicaciones. En principio, deberíamos prohibir la llamada directa a servicios de dominio entre agregados y la asociación de tablas de datos entre agregados.

capa de interfaz de usuario

La capa de interfaz de usuario es un puente para el acceso a servicios y el intercambio de datos entre aplicaciones front-end y microservicios. Maneja la solicitud Restful enviada por el front-end y analiza los archivos de configuración ingresados por el usuario, etc., y pasa los datos a la capa de aplicación. O después de obtener los datos del servicio de la aplicación, realizar el ensamblaje de datos y proporcionar servicios de datos al front-end. La forma de servicio principal es el servicio de fachada.

El servicio de fachada se divide en interfaz e implementación. Complete la orientación del servicio, la conversión y el ensamblaje de datos DO y DTO, y realice la conversión y el intercambio de datos de la capa de aplicación y front-end.

4. Dependencias de servicios de arquitecturas de dos capas.

Ahora revisemos la arquitectura en capas DDD. Un principio importante de la arquitectura en capas es que cada capa solo se puede acoplar con la capa debajo de ella. Según la rigidez del acoplamiento, la arquitectura en capas se puede dividir en dos tipos: arquitectura en capas estricta y arquitectura en capas sueltas.

En una arquitectura estrictamente en capas, cualquier capa sólo puede depender de la capa directamente debajo de ella. En una arquitectura con capas sueltas, cualquier capa puede depender de cualquier capa debajo de ella.

Analicemos y comparemos en detalle estas dos arquitecturas en capas.

Dependencias de servicios en una arquitectura con capas flexibles

Echemos un vistazo a la siguiente imagen: en la arquitectura de capas sueltas, los métodos de entidad y los servicios de dominio de la capa de dominio se pueden exponer directamente a la capa de aplicación y a la capa de interfaz de usuario. Las dependencias de servicio de la arquitectura de capas sueltas se pueden exponer rápidamente a la capa superior sin encapsulación nivel por nivel.

Pero tiene algunos problemas: el primero es que es fácil exponer la lógica de implementación del negocio central de la capa de dominio, el segundo es que cuando el método de entidad o el servicio de dominio cambia, porque el servicio es llamado y combinado por múltiples servicios de capa al mismo tiempo, no es fácil descubrirlo. Es inconveniente notificar a todas las personas que llaman qué servicios de nivel superior llaman y los combinan.

Veamos otra imagen: en la arquitectura de capas sueltas, el método de la entidad A se expone a la capa de interfaz de usuario aFacade después de combinar la capa de aplicación. El servicio de dominio abDomainService cruza directamente la capa de aplicación y está expuesto al servicio abFacade de la capa de interfaz de usuario. Cualquier servicio de nivel inferior en una arquitectura de capas flexibles puede exponerse a servicios de nivel superior.

Estricta arquitectura en capas de dependencias de servicios.

Echemos un vistazo a la siguiente imagen: en una arquitectura en capas estricta, cada capa de servicios solo puede proporcionar servicios a la capa inmediatamente anterior. Aunque las entidades, los métodos de entidad y los servicios de dominio están todos en la capa de dominio, las entidades y los métodos de entidad solo pueden exponerse a servicios de dominio y los servicios de dominio solo pueden exponerse a servicios de aplicaciones.

En una arquitectura estrictamente en capas, si es necesario llamar a un servicio a través de capas, el servicio de la capa inferior debe encapsularse en la capa superior antes de que pueda proporcionar el servicio entre capas. Por ejemplo, los métodos de entidad deben proporcionar servicios a servicios de aplicaciones, que deben encapsularse en servicios de dominio.

Esto se debe a que a través de la encapsulación, puede evitar exponer la implementación de la lógica empresarial central al exterior, encapsular entidades y métodos en servicios de dominio y evitar depositar demasiada lógica empresarial central que debería pertenecer a la capa de dominio en la capa de aplicación. . Además, cuando un servicio cambia, dado que el servicio solo es llamado y combinado por el servicio al lado de la capa superior, solo necesita notificar a la siguiente capa superior paso a paso. La capacidad de administración del servicio es mejor que la arquitectura de capas sueltas.

Sigamos mirando la imagen: el método de entidad A debe encapsularse en el servicio de dominio aDomainService antes de poder exponerse al servicio de aplicación aAppService. Después de que abDomainService combine y encapsule los métodos de las entidades A y B, se expone al servicio de aplicación abAppService.