Table des matières
Alors, quel rôle l’agrégation y joue-t-elle ?
Comment concevoir l’agrégation ?
Quelques principes de conception pour l'agrégation
Cet article parle de l'agrégation (Aggregate) et de la racine d'agrégation (AggregateRoot).
Commençons par examiner l'article précédent.Dans la tempête d'événements, nous trouverons des entités (Entity) ou des objets de valeur (ValueObject) en fonction de certaines opérations et comportements commerciaux, puis combinerons des entités et des objets de valeur étroitement liés à l'entreprise pour former une agrégation. Définissez ensuite plusieurs agrégats dans le même contexte limité (Contexte limité) en fonction de la sémantique métier et complétez la modélisation de domaine dans le contexte limité.
Alors savez-vous pourquoi les deux concepts d'agrégation et de racine d'agrégation sont ajoutés entre le contexte borné et l'entité ? Quelles sont leurs fonctions ? Comment concevoir l’agrégation ? C’est sur cela que nous allons nous concentrer dans cette conférence.
polymérisation
Dans DDD, les entités et les objets de valeur sont des objets de domaine très basiques. Une entité correspond généralement à un objet métier, qui possède des attributs métier et des comportements métier ; tandis qu'un objet de valeur est principalement un ensemble d'attributs, qui décrivent l'état et les caractéristiques de l'entité. Mais les entités et les objets de valeur ne sont que des objets individualisés, et leurs comportements montrent les capacités des individus.
Alors, quel rôle l’agrégation y joue-t-elle ?
Par exemple. La société est composée d'individus qui symbolisent chacun de nous. Avec le développement de la société, des associations, des institutions, des départements et d'autres organisations ont progressivement émergé. Nous sommes passés d'individus à membres de l'organisation. Tout le monde peut travailler ensemble pour avancer vers le plus grand objectif et jouer un plus grand rôle de force.
Les entités et les objets de valeur dans le modèle de domaine sont comme des individus, et l'organisation qui permet aux entités et aux objets de valeur de travailler ensemble est l'agrégation, qui est utilisée pour garantir que ces objets de domaine peuvent assurer la cohérence des données lors de la mise en œuvre d'une logique métier commune.
Vous pouvez comprendre que l'agrégation est une combinaison d'entités et d'objets de valeur étroitement liés au métier et à la logique. L'agrégation est l'unité de base de la modification et de la persistance des données. Chaque agrégation correspond à un entrepôt pour assurer la persistance des données.
L'agrégation a une racine globale et une limite de contexte.Cette frontière définit quelles entités et objets de valeur doivent être contenus dans l'agrégat selon le principe de responsabilité commerciale unique et de cohésion élevée, et les frontières entre les agrégats sont faiblement couplées. Les microservices ainsi conçus sont naturellement « à haute cohésion et faible couplage ».
L'agrégation appartient à la couche de domaine dans l'architecture en couches DDD, et la couche de domaine contient plusieurs agrégations pour implémenter conjointement la logique métier de base. Les entités globales mettent en œuvre des capacités commerciales individuelles et une forte cohésion de la logique commerciale avec un modèle sanglant. La logique métier sur plusieurs entités est implémentée via les services de domaine, et la logique métier sur plusieurs agrégats est implémentée via les services d'application. Par exemple, si certains scénarios métier nécessitent que les mêmes entités agrégées A et B soient complétées ensemble, nous pouvons implémenter cette logique métier avec des services de domaine ; tandis que certaines logiques métier nécessitent deux services dans l'agrégat C et l'agrégat D Ensemble, vous pouvez ensuite utiliser Application Services pour combiner les deux services.
racine globale
L'objectif principal de la racine agrégée est d'éviter le problème d'incohérence des données entre l'agrégation et les entités en raison du manque de contrôle unifié des règles métier dans le modèle de données complexe.
Chaque entité dans le modèle de données traditionnel est égale. Si les entités sont autorisées à effectuer des appels et des modifications de données incontrôlés, cela risque de provoquer des incohérences logiques de données entre les entités. Cependant, si la méthode de verrouillage est utilisée, la complexité du logiciel augmentera et les performances du système seront également réduites.
Si l’agrégat est comparé à une organisation, alors la racine de l’agrégat est la personne en charge de l’organisation. La racine de l'agrégat est également appelée entité racine, qui n'est pas seulement l'entité, mais également le gestionnaire de l'agrégat.
Tout d'abord, en tant qu'entité elle-même, elle possède les attributs et le comportement commercial de l'entité et réalise sa propre logique commerciale.
Deuxièmement, en tant que gestionnaire de l'agrégation, il est chargé de coordonner les entités et les objets de valeur au sein de l'agrégation pour compléter une logique métier commune conformément à des règles métier fixes.
Enfin, entre les agrégats, il s'agit également de l'interface externe des agrégats, acceptant les tâches et demandes externes sous la forme d'association d'ID racine d'agrégat et réalisant une collaboration commerciale entre les agrégats dans le contexte. Autrement dit, les agrégats sont référencés via l'ID racine de l'agrégat. Si vous devez accéder aux entités d'autres agrégats, vous devez d'abord accéder à la racine de l'agrégat, puis accéder aux entités internes de l'agrégat. Les objets externes ne peuvent pas accéder directement à l'agrégat. entités dans leur ensemble.
Comment concevoir l’agrégation ?
La modélisation de domaine DDD utilise généralement la tempête d'événements, qui utilise généralement des méthodes telles que l'analyse de cas d'utilisation, l'analyse de scénarios et l'analyse du parcours utilisateur pour répertorier tous les comportements et événements commerciaux possibles via un brainstorming, puis découvrir les objets de domaine qui génèrent ces comportements et trier le domaine La relation entre les objets, découvrez la racine agrégée, découvrez l'entité et l'objet de valeur étroitement liés à l'activité racine agrégée, puis combinez la racine agrégée, l'entité et l'objet de valeur pour construire un agrégat.
Prenons le scénario du secteur de l'assurance comme exemple pour voir quelles sont les étapes impliquées dans le processus de construction d'agrégats.
Étape 1 : Utilisez des tempêtes d'événements pour trier toutes les entités et objets de valeur qui se produisent pendant le processus de demande d'assurance, tels que les formulaires de demande d'assurance, les cibles, les clients, les assurés, etc., en fonction des comportements commerciaux.
Étape 2 : Sélectionnez l'entité racine qui convient comme gestionnaire d'objets parmi de nombreuses entités, c'est-à-dire la racine agrégée. Pour juger si une entité est une racine agrégée, vous pouvez combiner l’analyse de scénario suivante : A-t-elle un cycle de vie indépendant ? Existe-t-il un identifiant unique au monde ? D’autres objets peuvent-ils être créés ou modifiés ? Existe-t-il un module dédié pour gérer cette entité. Les racines globales dans le diagramme sont respectivement la police d’assurance et les entités client.
Étape 3 : Selon le principe de responsabilité commerciale unique et de cohésion élevée, découvrez toutes les entités étroitement dépendantes et les objets de valeur associés à la racine agrégée. Construisez une collection d'objets contenant la racine d'agrégation (unique), plusieurs entités et objets de valeur, et cette collection est une agrégation. Dans la figure, nous avons construit deux agrégations de client et d'assurance.
Étape 4 : Dessinez des modèles de référence et de dépendance d'objet au sein de l'agrégat en fonction des dépendances de l'objet racine, de l'entité et de la valeur de l'agrégat. Ici je dois expliquer : les données du preneur d'assurance et de l'assuré sont obtenues à partir de l'agrégation clients en associant l'identifiant client. Dans l'agrégation assurance, ce sont les objets de valeur du formulaire de demande d'assurance, et les données de ces objets de valeur sont les données redondantes du client. , même si les données client agrégées changent à l'avenir, cela n'affectera pas les données d'objet de valeur du formulaire de demande d'assurance. À partir de la figure, nous pouvons également voir la relation de référence entre les entités.Par exemple, dans l'agrégation d'assurance, la racine de l'agrégat de police d'assurance fait référence à l'entité de cotation et l'entité de cotation fait référence à la sous-entité de la règle de cotation.
Étape 5 : Plusieurs agrégations sont divisées dans le même contexte délimité en fonction de la sémantique et du contexte métier.
C'est le processus complet de la naissance d'une agrégation.
Quelques principes de conception pour l'agrégation
Autant jeter un œil à la description des principes de conception d'agrégation dans le livre "Implementing Domain-Driven Design". Le texte original est un peu difficile à comprendre, alors laissez-moi vous l'expliquer.
1. Modélisez les véritables conditions invariantes dans les limites de cohérence. Les agrégations sont utilisées pour encapsuler la véritable immuabilité, plutôt que de simplement regrouper des objets. Il existe un ensemble de règles métier immuables dans l'agrégation. Chaque entité et objet de valeur fonctionne selon les règles métier unifiées pour assurer la cohérence des données d'objet. Tout ce qui se trouve en dehors des limites n'a rien à voir avec l'agrégation. C'est ainsi que l'agrégation peut réaliser raison de la forte cohésion des entreprises.
2. Concevoir de petits agrégats. Si l'agrégation est conçue de manière trop volumineuse, elle contiendra trop d'entités, ce qui entraînera une gestion trop compliquée entre les entités, et des conflits de concurrence ou des verrous de base de données se produiront lors d'opérations à haute fréquence, ce qui conduira finalement à une mauvaise disponibilité du système. La conception d'une petite agrégation peut réduire la possibilité de refactorisation de l'agrégation en raison d'une entreprise trop grande et rendre le modèle de domaine plus adaptable aux changements commerciaux.
3. Référencez d’autres agrégats par leurs identifiants uniques. Les agrégats sont référencés en associant des ID racine d'agrégat externes, plutôt que des références d'objet directes. Les objets des agrégats externes sont gérés dans les limites des agrégats, ce qui peut facilement conduire à des limites floues des agrégats et augmenter le degré de couplage entre les agrégats.
4. Utilisez une cohérence éventuelle en dehors des limites. Les données au sein de l'agrégation sont fortement cohérentes, et les données entre les agrégations sont finalement cohérentes. L’état d’au plus un agrégat peut être modifié en une seule transaction. Si une opération commerciale implique des changements dans l'état de plusieurs agrégats, les événements de domaine doivent être utilisés pour modifier de manière asynchrone les agrégats associés afin d'obtenir un découplage entre les agrégats (j'expliquerai le contenu pertinent dans la section des événements de domaine).
5. Réalisez des appels de service inter-agrégations via la couche application. Afin de réaliser le découplage entre les agrégats dans les microservices, ainsi que la combinaison et la division des microservices en unités d'agrégats à l'avenir, les appels de services de domaine entre agrégats et les associations de tables de bases de données entre agrégats doivent être évités.
Les principes ci-dessus sont quelques principes généraux de conception de DDD, ou la même phrase : « Celui qui vous convient est le meilleur. » Au cours du processus de conception du système, vous devez tenir compte de la situation spécifique du projet. Si vous êtes confronté à la commodité d'utilisation , exigences de haute performance, manque de capacités techniques et gestion globale des transactions et autres facteurs d'influence, ces principes ne sont pas impossibles à briser. En bref, tout commence par la résolution de problèmes pratiques.
Résumer
[Article précédent] et le contenu de cet article sont en fait fortement liés. Autant résumer ici les connexions et les différences entre les agrégats, les racines des agrégats, les entités et les objets de valeur.
Les caractéristiques de l'agrégation : cohésion élevée, faible couplage, c'est la limite la plus basse du modèle de domaine, elle peut être utilisée comme la plus petite unité pour diviser les microservices, mais je ne vous recommande pas de trop diviser les microservices. Cependant, dans des scénarios avec des exigences de performances extrêmes, l'agrégation peut être utilisée indépendamment comme microservice pour répondre à la publication à haute fréquence des versions et à l'évolutivité élastique ultime.
Un microservice peut contenir plusieurs agrégats, et la frontière entre les agrégats est une frontière logique naturelle au sein du microservice. Avec cette limite logique, lorsque l'architecture des microservices évolue, elle peut être divisée et combinée en unités d'agrégation, et l'évolution de l'architecture des microservices n'est plus une tâche difficile.
Les caractéristiques de la racine agrégée : la racine agrégée est une entité qui possède les caractéristiques d'une entité, possède un identifiant globalement unique et a un cycle de vie indépendant. Un agrégat n'a qu'une seule racine d'agrégat. La racine d'agrégat organise et coordonne les entités et les objets de valeur au sein de l'agrégat au moyen de références d'objet directes. La racine d'agrégat et la racine d'agrégat réalisent la synergie entre les agrégats au moyen d'une association d'ID.
Les caractéristiques de l'entité : elle a un identifiant, et l'égalité est jugée par l'identifiant, et l'identifiant n'est unique que dans l'agrégation. L'état est mutable, il est attaché à la racine de l'agrégat et son cycle de vie est géré par la racine de l'agrégat. Les entités sont généralement persistantes, mais pas nécessairement dans une relation un-à-un avec les objets persistants de la base de données. Les entités peuvent faire référence à des racines d'agrégat, à des entités et à des objets de valeur au sein d'un agrégat.
Les caractéristiques des objets de valeur : pas d'identifiant, immuable, pas de cycle de vie, à jeter une fois épuisé. L'égalité entre les objets de valeur est jugée par la valeur de l'attribut. Son essence fondamentale est la valeur, qui est un ensemble d’attributs conceptuellement complets utilisés pour décrire l’état et les caractéristiques des entités. Les objets de valeur essaient de référencer uniquement des objets de valeur.