Tabla de contenido
Entonces, ¿qué papel juega la agregación en esto?
Algunos principios de diseño para la agregación
Este artículo habla sobre la agregación (Aggregate) y la raíz de agregación (AggregateRoot).
Primero revisemos el artículo anterior: en la tormenta de eventos, encontraremos entidades (Entity) u objetos de valor (ValueObject) en función de algunas operaciones y comportamientos comerciales, y luego combinaremos entidades y objetos de valor estrechamente relacionados con el negocio para formar una agregación. Luego, defina varios agregados en el mismo contexto delimitado (contexto delimitado) de acuerdo con la semántica empresarial y complete el modelado de dominio en el contexto delimitado.
Entonces, ¿sabes por qué se agregan los dos conceptos de agregación y raíz de agregación entre el contexto acotado y la entidad? ¿Cuáles son sus funciones? ¿Cómo diseñar agregación? Esto es en lo que nos centraremos en esta conferencia.
polimerización
En DDD, las entidades y los objetos de valor son objetos de dominio muy básicos. Una entidad generalmente corresponde a un objeto de negocio, que tiene atributos de negocio y comportamientos de negocio; mientras que un objeto de valor es principalmente una colección de atributos que describen el estado y las características de la entidad. Pero las entidades y los objetos de valor son sólo objetos individualizados y sus comportamientos muestran las capacidades de los individuos.
Entonces, ¿qué papel juega la agregación en esto?
Por ejemplo. La sociedad está formada por individuos que simbolizan a cada uno de nosotros. Con el desarrollo de la sociedad, han ido surgiendo asociaciones, instituciones, departamentos y otras organizaciones. Hemos pasado de ser individuos a miembros de la organización. Todos pueden trabajar juntos para avanzar hacia el objetivo más importante y desempeñar un papel más importante.
Las entidades y los objetos de valor en el modelo de dominio son como individuos, y la organización que permite que las entidades y los objetos de valor trabajen juntos es la agregación, que se utiliza para garantizar que estos objetos de dominio puedan garantizar la coherencia de los datos al implementar una lógica empresarial común.
Se puede entender que la agregación es una combinación de entidades y objetos de valor que están estrechamente relacionados con el negocio y la lógica. La agregación es la unidad básica de modificación y persistencia de datos. Cada agregación corresponde a un almacén para lograr la persistencia de los datos.
La agregación tiene una raíz agregada y un límite de contexto. Este límite define qué entidades y objetos de valor deben estar contenidos dentro del agregado de acuerdo con el principio de responsabilidad empresarial única y alta cohesión, y los límites entre los agregados están débilmente acoplados. Los microservicios diseñados de esta manera son, naturalmente, de "alta cohesión y bajo acoplamiento".
La agregación pertenece a la capa de dominio en la arquitectura en capas DDD, y la capa de dominio contiene múltiples agregaciones para implementar conjuntamente la lógica empresarial central. Las entidades en conjunto implementan capacidades comerciales individuales y una alta cohesión de la lógica comercial con un modelo sangriento. La lógica empresarial en múltiples entidades se implementa a través de servicios de dominio y la lógica empresarial en múltiples agregados se implementa a través de servicios de aplicaciones. Por ejemplo, si algunos escenarios de negocios requieren que las mismas entidades agregadas A y B se completen juntas, podemos implementar esta lógica de negocios con servicios de dominio; mientras que algunas lógicas de negocios requieren dos servicios en el agregado C y el agregado D para completarlos juntos, entonces puede usar servicios de aplicaciones para combinar estos dos servicios.
raíz agregada
El objetivo principal de la raíz agregada es evitar el problema de la inconsistencia de datos entre la agregación y las entidades debido a la falta de control de reglas comerciales unificadas en el modelo de datos complejo.
Todas las entidades en el modelo de datos tradicional son iguales. Si a las entidades se les permite realizar llamadas y modificaciones de datos sin control, es probable que se produzcan inconsistencias en la lógica de los datos entre las entidades. Sin embargo, si se utiliza el método de bloqueo, la complejidad del software aumentará y también se reducirá el rendimiento del sistema.
Si se compara el agregado con una organización, entonces la raíz agregada es la persona a cargo de la organización. La raíz agregada también se denomina entidad raíz, que no solo es la entidad, sino también el administrador del agregado.
En primer lugar, como entidad misma, tiene los atributos y el comportamiento comercial de la entidad y realiza su propia lógica comercial.
En segundo lugar, como administrador de la agregación, es responsable de coordinar entidades y objetos de valor dentro de la agregación para completar la lógica comercial común de acuerdo con reglas comerciales fijas.
Finalmente, entre agregados, también es la interfaz externa de los agregados, que acepta tareas y solicitudes externas en forma de asociación de ID de raíz agregada y realiza la colaboración comercial entre agregados dentro del contexto. Es decir, se hace referencia a los agregados a través del ID de la raíz del agregado. Si necesita acceder a las entidades de otros agregados, primero debe acceder a la raíz del agregado y luego navegar a las entidades internas del agregado. Los objetos externos no pueden acceder directamente al entidades en conjunto.
¿Cómo diseñar agregación?
El modelado de dominio DDD generalmente utiliza tormenta de eventos, que generalmente utiliza métodos como análisis de casos de uso, análisis de escenarios y análisis del recorrido del usuario para enumerar todos los posibles comportamientos y eventos comerciales a través de una lluvia de ideas, y luego descubrir los objetos de dominio que generan estos comportamientos y clasificarlos. el dominio La relación entre objetos, descubra la raíz agregada, descubra la entidad y el objeto de valor estrechamente relacionados con el negocio de la raíz agregada, y luego combine la raíz agregada, la entidad y el objeto de valor para construir un agregado.
Tomemos como ejemplo el escenario del negocio de seguros para ver qué pasos están involucrados en el proceso de construcción agregada.
Paso 1: utilice tormentas de eventos para clasificar todas las entidades y objetos de valor que ocurren durante el proceso de solicitud de seguro, como formularios de solicitud de seguro, objetivos, clientes, asegurados, etc., en función del comportamiento comercial.
Paso 2: Seleccione la entidad raíz que sea adecuada como administrador de objetos entre muchas entidades, es decir, la raíz agregada. Para juzgar si una entidad es una raíz agregada, se puede combinar el siguiente análisis de escenario: ¿Tiene un ciclo de vida independiente? ¿Existe una identificación única a nivel mundial? ¿Se pueden crear o modificar otros objetos? ¿Existe un módulo dedicado para gestionar esta entidad? Las raíces agregadas en el diagrama son la póliza de seguro y las entidades del cliente, respectivamente.
Paso 3: De acuerdo con el principio de responsabilidad empresarial única y alta cohesión, descubra todas las entidades estrechamente dependientes y los objetos de valor asociados con la raíz agregada. Construya una colección de objetos que contenga la raíz agregada (única), múltiples entidades y objetos de valor, y esta colección es agregación. En la figura, hemos construido dos agregaciones de clientes y seguros.
Paso 4: Dibujar modelos de referencia y dependencia de objetos dentro del agregado de acuerdo con las dependencias de la raíz, la entidad y el objeto de valor agregados. Aquí necesito explicar: los datos del tomador y del asegurado se obtienen de la agregación de clientes asociando el ID del cliente, en la agregación de seguros son los objetos de valor del formulario de solicitud de seguro, y los datos de estos objetos de valor son los datos redundantes del cliente. , incluso si los datos agregados del cliente cambian en el futuro, no afectará los datos del objeto de valor del formulario de solicitud de seguro. En la figura, también podemos ver la relación de referencia entre entidades. Por ejemplo, en la agregación de seguros, la raíz agregada de la póliza de seguro se refiere a la entidad de cotización y la entidad de cotización se refiere a la subentidad de regla de cotización.
Paso 5: varias agregaciones se dividen en el mismo contexto delimitado según la semántica y el contexto empresarial.
Este es el proceso completo del nacimiento de una agregación.
Algunos principios de diseño para la agregación
También podríamos echar un vistazo a la descripción de los principios de diseño de agregación en el libro "Implementación del diseño basado en dominios". El texto original es un poco difícil de entender, así que déjame explicártelo.
1. Modele las verdaderas condiciones invariantes dentro de los límites de consistencia. Las agregaciones se utilizan para encapsular la verdadera inmutabilidad, en lugar de simplemente agrupar objetos. Hay un conjunto de reglas comerciales inmutables en la agregación. Cada entidad y objeto de valor opera de acuerdo con las reglas comerciales unificadas para lograr la coherencia de los datos del objeto. Cualquier cosa fuera del límite no tiene nada que ver con la agregación. Así es como la agregación puede lograr Razón de la alta cohesión empresarial.
2. Diseñar pequeños agregados. Si el diseño de la agregación es demasiado grande, la agregación contendrá demasiadas entidades, lo que resultará en una administración demasiado complicada entre entidades, y se producirán conflictos de concurrencia o bloqueos de la base de datos durante las operaciones de alta frecuencia, lo que eventualmente conducirá a una mala disponibilidad del sistema. El diseño de agregación pequeña puede reducir la posibilidad de refactorización de la agregación debido a negocios demasiado grandes y hacer que el modelo de dominio sea más adaptable a los cambios comerciales.
3. Haga referencia a otros agregados por sus identificadores únicos. Se hace referencia a los agregados asociando ID de raíz de agregados externos, en lugar de referencias directas a objetos. Los objetos de agregados externos se gestionan dentro de los límites de los agregados, lo que fácilmente puede conducir a límites poco claros de los agregados y aumentar el grado de acoplamiento entre los agregados.
4. Utilice la coherencia eventual fuera de los límites. Los datos dentro de la agregación son fuertemente consistentes y los datos entre las agregaciones eventualmente son consistentes. El estado de como máximo un agregado se puede cambiar en una sola transacción. Si una operación comercial implica el cambio de múltiples estados de agregación, los eventos de dominio deben usarse para modificar de forma asincrónica las agregaciones relacionadas para lograr el desacoplamiento entre las agregaciones (explicaré el contenido relacionado en detalle en la sección de eventos de dominio).
5. Realizar llamadas de servicios de agregación cruzada a través de la capa de aplicación. Para lograr el desacoplamiento entre agregados en microservicios, así como la combinación y división de microservicios en unidades de agregados en el futuro, se deben evitar las llamadas a servicios de dominio entre agregados y las asociaciones de tablas de bases de datos entre agregados.
Los principios anteriores son algunos principios generales de diseño de DDD, o la misma frase: "El que más le convenga es el mejor ". Durante el proceso de diseño del sistema, debe considerar la situación específica del proyecto. Si se enfrenta a la conveniencia uso, requisitos de alto rendimiento, falta de capacidades técnicas y gestión general de transacciones y otros factores influyentes, estos principios no son imposibles de superar. En resumen, todo comienza con la resolución de problemas prácticos.
Resumir
[Artículo anterior] y el contenido de este artículo en realidad están fuertemente relacionados. También podríamos resumir aquí las conexiones y diferencias entre agregados, raíces agregadas, entidades y objetos de valor.
Las características de la agregación: alta cohesión, bajo acoplamiento, es el límite más bajo en el modelo de dominio y se puede usar como la unidad más pequeña para dividir microservicios, pero no recomiendo dividir demasiado los microservicios. Sin embargo, en escenarios con requisitos de rendimiento extremos, Aggregation se puede utilizar de forma independiente como un microservicio para cumplir con los lanzamientos de versiones de alta frecuencia y una escalabilidad elástica extrema.
Un microservicio puede contener varios agregados y el límite entre los agregados es un límite lógico natural dentro del microservicio. Con este límite lógico, cuando la arquitectura de microservicios evoluciona, se puede dividir y combinar en unidades de agregación, y la evolución de la arquitectura de microservicios ya no es una tarea difícil.
Las características de la raíz agregada: la raíz agregada es una entidad que tiene las características de una entidad, tiene un identificador único global y tiene un ciclo de vida independiente. Un agregado tiene solo una raíz agregada. La raíz agregada organiza y coordina entidades y objetos de valor dentro del agregado por medio de referencias directas a objetos. La raíz agregada y la raíz agregada realizan la sinergia entre agregados mediante asociación de ID.
Las características de la entidad: tiene una identificación, la igualdad se juzga por la identificación y la identificación solo es única en la agregación. El estado es mutable, está adjunto a la raíz agregada y su ciclo de vida lo gestiona la raíz agregada. Las entidades son generalmente persistentes, pero no necesariamente en una relación uno a uno con los objetos persistentes de la base de datos. Las entidades pueden hacer referencia a raíces agregadas, entidades y objetos de valor dentro de un agregado.
Las características de los objetos de valor: sin identificación, inmutables, sin ciclo de vida, desechar cuando se agotan. La igualdad entre objetos de valor se juzga por el valor del atributo. Su esencia central es el valor, que es un conjunto de atributos conceptualmente completos que se utilizan para describir el estado y las características de las entidades. Los objetos de valor intentan hacer referencia únicamente a objetos de valor.