L'essor du DDD
Nous savons tous qu'avec le développement des équipements et de la technologie ces dernières années, l'architecture logicielle a subi de nombreux changements, de l'architecture autonome initiale (BS/CS) à l'architecture centralisée ultérieure, puis à l'architecture microservice d'aujourd'hui. peut fondamentalement dire qu'à l'ère de la prévalence de l'architecture des microservices, DDD a été proposé par Eric Evans dès 2004, mais il est resté dans un état stagnant jusqu'à ce que les "Microservices" de Martin Fowler attirent l'attention de tous, c'est-à-dire après la prévalence des microservices (ici Il convient de noter que le premier proposant des microservices n'est pas Martin Fowler, mais Fred George), et DDD est revenu dans la vision des gens. Pourquoi ?
Voyons d'abord l'évolution et les principales différences des trois architectures techniques :
la première étape est une architecture autonome, qui se caractérise par la conception et le développement de l'ensemble du développement autour de la base de données.
La deuxième étape est une architecture centralisée à trois niveaux, qui adopte une méthode de conception orientée objet. La logique métier est divisée en couche métier, couche logique et couche d'accès aux données. Cette architecture est facile à gonfler à une ou plusieurs couches, et l'évolutivité De plus, la loi de Moore n'est pas valide et les performances d'une seule machine sont limitées.
La troisième étape est l'architecture de microservice. Dans l'architecture centralisée, l'analyse, la conception et le développement du système sont souvent effectués de manière indépendante, et la personne en charge de chaque étape peut être différente, ce qui implique le problème de la perte d'informations de communication. , le projet part de l'analyse Le processus de développement est très long et il est facile que la conception finale du développement soit différente des exigences Les microservices résolvent principalement ces points faibles dans la deuxième étape, réalisent le découplage entre les applications et résolvent les problème d'évolutivité des applications individuelles.
Problèmes avec les microservices
Après être entré dans le microservice, de nombreux problèmes d'application monolithique de l'architecture centralisée ont été résolus, mais de nouveaux problèmes sont apparus au fur et à mesure que les temps l'exigeaient. Quelle doit être la granularité du microservice ? Comment concevoir des microservices ? Comment diviser les microservices ? Où sont les limites des microservices ?
Les gens n'ont pas résolu ce problème depuis longtemps, et même Martin Fowler ne nous a pas dit comment diviser les microservices lorsqu'il a proposé l'architecture des microservices.
Même pendant longtemps, les gens ont eu des malentendus sur le fractionnement des microservices. Certaines personnes pensent : "Les microservices sont très simples, c'est-à-dire diviser l'application monolithique précédente en plusieurs packages de déploiement, ou diviser l'architecture d'application monolithique d'origine. Remplacez-la avec une architecture technique qui prend en charge les microservices, et ce sont des microservices. » Certaines personnes pensent que les microservices devraient être divisés aussi petits que possible.
Compte tenu de la situation ci-dessus, de nombreux projets sont trop complexes en raison d'un fractionnement excessif au début, ce qui rend difficile l'exploitation et la maintenance ou même la mise en ligne à un stade ultérieur.
On peut en conclure que la cause première du dilemme du fractionnement des microservices est de ne pas savoir où se trouve la frontière de l'entreprise ou du microservice. En d'autres termes, une fois que la frontière métier et la frontière application sont déterminées, ce dilemme sera résolu .
DDD résout le problème de la détermination des frontières métier. On voit que DDD n'est pas une architecture technique, mais une méthodologie pour diviser le périmètre des domaines métiers. L'essor de DDD est dû au fait que de nombreux ingénieurs familiarisés avec la modélisation pilotée par le domaine (DDD) constatent que lors de la conception de microservices, l'utilisation des idées DDD pour le tri des entreprises peut bien planifier les limites de service et atteindre des microservices internes et externes élevés. poly , faible couplage . Ainsi, de plus en plus de personnes considèrent DDD comme l'idéologie directrice de la division commerciale.
Présentation de la DDD
DDD est une méthode de démantèlement des affaires, de division des affaires et de détermination des limites des affaires. C'est une idée de conception de domaine très complexe. Il divise nos problèmes en domaines et essaie de séparer la complexité de la mise en œuvre technique. La solution principale C'est un problème que le logiciel est difficile à comprendre et difficile à faire évoluer. DDD n'est pas une architecture, mais une méthodologie architecturale. Le but est de simplifier les problèmes complexes et de nous aider à concevoir des domaines et des frontières clairs, qui peuvent bien rendre compte de l'évolution de l'architecture technique. .
1. La conception axée sur le domaine est basée sur la modélisation de domaine plutôt que sur la modélisation de données.
Dans l'exemple ci-dessus, avant la refactorisation du code, l'entité d'activité n'a que des attributs de base et des méthodes get/set, c'est-à-dire le "modèle de perte de sang", qui provoque l'objet de domaine d'activité dégénère en un objet de données, utilisé uniquement comme crud pour les composants orm, les modèles de saignement peuvent être vus partout dans le code du projet. La raison est directement liée à la popularité du mécanisme de persistance du mappage objet-relationnel (ORM, tel que l'hibernation). Utilisez ORM pour mapper chaque classe à une table de données et parcourir les objets d'entité. Au fil du temps, les entités deviennent orm Un terme pour un cadre qui perd des capacités de domaine. Lors de la conception d'un projet, nous devons y penser du point de vue du domaine métier, et non du point de vue de la base de données, dont nous parlerons en détail dans la section sur la conception stratégique.
2. Rencontrez la conception de l'architecture hexagonale.L'architecture
hexagonale sera présentée en détail plus tard.L'architecture en oignon et l'architecture propre sont similaires à l'architecture hexagonale.
Si les deux points ci-dessus sont respectés et que certains concepts de DDD sont cartographiés et mis en pratique, votre système est déjà conforme à DDD. Pour résumer, DDD n'est pas une toute nouvelle architecture spéciale, mais le point final que tout code de projet atteindra après refactorisation pour répondre à une maintenabilité élevée, une évolutivité élevée, une testabilité élevée et une structure de code claire.
DDD se compose de deux parties, la partie conception stratégique et la partie conception tactique
La conception stratégique part principalement du point de vue commercial, établit un modèle de domaine métier, divise les limites de domaine et établit un contexte délimité d'un langage commun. Le contexte délimité peut être utilisé comme limite de référence pour la conception de microservices.
La conception tactique commence d'un point de vue technique, se concentre sur la réalisation technique du modèle de domaine et complète le développement et la mise en œuvre du logiciel, y compris la conception et la mise en œuvre de la logique de code pour les racines agrégées, les entités, les objets de valeur, les services de domaine, les services d'application et les ressources. bibliothèques.
La conception stratégique DDD établira un modèle de domaine, qui est utilisé pour guider la conception et la division des microservices. La première étape de DDD consiste à organiser un brainstorming, ce qui peut être compris comme une discussion sur la compréhension de l'entreprise. Décomposer notre domaine d'activité sans omission, tout comme le pêcher tout à l'heure. La première chose à faire est d'analyser le plus possible pour s'assurer que chaque domaine peut être pris en compte. En pratique, l'analyse de cas d'utilisation et l'analyse de scénarios sont souvent utilisées. Et l'analyse du parcours utilisateur, Il s'agit d'un processus divergent. Au cours de la phase de brainstorming, de nombreux objets de domaine tels que des entités, des commandes et des événements seront générés. Nous les regroupons à partir de différentes dimensions pour former des limites telles que l'agrégation et des contextes délimités, et établir des modèles de domaine. Il s'agit d'un processus convergent.
Plus précisément, nous pouvons déterminer le modèle de domaine et les limites du microservice en trois étapes.
Étape 1 : triez les opérations utilisateur, les événements et les dépendances externes dans le processus métier dans la tempête d'événements, et triez les objets de domaine tels que les entités de domaine en fonction de ces éléments.
Étape 2 : selon la corrélation commerciale entre les entités de domaine, combinez des entités étroitement liées à l'entreprise pour former une agrégation et déterminez la racine d'agrégation, l'objet de valeur et l'entité dans l'agrégation. Dans cette figure, la limite entre les agrégats est la première limite de couche, ils s'exécutent dans la même instance de microservice, cette limite est une limite logique, elle est donc représentée par une ligne pointillée.
Étape 3 : En fonction de facteurs tels que les frontières métier et sémantiques, définissez un ou plusieurs agrégats dans un contexte délimité pour former un modèle de domaine. Dans cette figure, la limite entre les contextes délimités est la limite de la deuxième couche, qui peut être la limite des futurs microservices. La logique de domaine dans différents contextes délimités est isolée et exécutée dans différentes instances de microservice, interagissant physiquement les unes avec les autres. est une frontière physique, et la frontière est représentée par une ligne continue.
En plus des champs, des agrégations et des entités, des mots tels que les racines d'agrégats et les objets de valeur apparaissent dans ce qui précède. En outre, il existe un langage de modélisation unifié, des sous-domaines, des domaines principaux, des domaines généraux, des domaines de support, etc., qui sont en fait du papier. tigres. Comme mentionné précédemment Après cela, afin de faciliter la discussion d'un certain domaine, certains concepts sont souvent formés. Ces concepts seront résumés par des noms. C'est ainsi que les noms ci-dessus viennent. C'est ce qu'on appelle le langage de modélisation unifié Hahaha, d'accord, pas de bêtises, je Les articles suivants expliqueront le sens de ces mots.Ici, nous discutons principalement des problèmes que DDD résout.
Trier la relation entre DDD et microservices . DDD est une méthode de conception architecturale, et les microservices sont un style architectural. Les deux sont essentiellement destinés à la poursuite d'une réactivité élevée et à séparer la complexité de la construction du système d'application d'un point de vue commercial. moyens. Les deux mettent l'accent sur le démarrage de l'entreprise, et leur essence principale est de mettre l'accent sur la division rationnelle des frontières de domaine en fonction du développement de l'entreprise, d'ajuster en permanence l'architecture existante et d'optimiser le code existant pour maintenir la vitalité de l'architecture et du code, ce que nous appellent souvent une architecture évolutive. . DDD se concentre principalement sur la division des frontières de domaine du point de vue des domaines métier, la construction d'un langage commun pour une communication efficace, l'établissement de modèles de domaine via l'abstraction métier et le maintien de la cohérence logique entre le métier et le code. Les microservices se concentrent principalement sur : la communication inter-processus, la tolérance aux pannes et l'isolation des pannes lors de l'exécution, réalisent une gestion décentralisée des données et une gouvernance de service décentralisée, et se concentrent sur le développement, les tests, la construction et le déploiement indépendants de microservices
Conception de la stratégie DDD
La conception stratégique part principalement du point de vue commercial, établit un modèle de domaine métier, divise les limites de domaine et établit un contexte délimité d'un langage commun. Le contexte délimité peut être utilisé comme limite de référence pour la conception de microservices.
Domaine : D'une manière générale, un domaine est ce que fait une organisation et tout ce qu'elle contient. Chaque entreprise ou organisation a son propre champ d'activité et sa propre façon de faire, ce champ d'activité et les activités qu'elle y mène sont des domaines. Lorsque vous développez un logiciel pour une entreprise, vous travaillez sur le domaine de cette entreprise. Ce champ doit être clair pour vous car vous travaillez dans ce domaine.
Pour le commerce du pourboire, le pourboire lui-même est le champ, c'est-à-dire le champ du pourboire. Que votre objet de pourboire soit un hôte, un film ou un article de blog, et que votre article de pourboire soit un RMB, une monnaie virtuelle, une fusée, etc., le pourboire est au cœur de ce champ.
Sous-domaine : pour les modèles de domaine contenant le mot "domaine", nous pourrions penser que l'ensemble du système d'entreprise crée un modèle unique, cohérent et entièrement fonctionnel. Alors ce n'est pas notre but avec DDD. Au contraire, dans DDD, un domaine est divisé en plusieurs petits domaines, et ces petits domaines sont des sous-domaines. En fait, lors du développement d'un modèle de domaine, nous nous concentrons généralement uniquement sur un certain aspect du système d'entreprise, et la division du domaine nous aidera à réussir.
Contexte délimité : une responsabilité spéciale délimitée par des limites d'affichage. Le modèle de domaine existe à l'intérieur de la frontière, et à l'intérieur de la frontière, chaque concept de modèle, y compris ses attributs et ses opérations, a une signification particulière.
Architecture en couches : un principe important de l'architecture en couches est que chaque couche ne peut être agrégée qu'avec la couche située en dessous.
Afin de réaliser le découplage de la définition et de la mise en œuvre de l'interface, la définition de l'interface se trouve au niveau de la couche domaine et la définition de la mise en œuvre se trouve au niveau de la couche infrastructure. Mais cela viole le principe de la dépendance unique de haut en bas. Afin de résoudre ce problème, nous adoptons ici le principe d'inversion de dépendance, et le contenu des modules de haut niveau du principe d'inversion de dépendance ne doit pas dépendre des modules de bas niveau, les deux doivent dépendre d'abstractions. Les abstractions ne doivent pas dépendre des détails, les détails doivent dépendre des abstractions. Selon ce principe, l'ajustement de la structure est le suivant :
Nous plaçons la couche d'infrastructure au-dessus de toutes les couches afin qu'elle implémente les interfaces définies par toutes les autres couches.
Lorsque nous adoptons le principe d'inversion des dépendances dans une architecture en couches, nous pouvons constater qu'en fait, le concept de superposition n'existe plus. Qu'ils soient de haut niveau ou de bas niveau, ils ne dépendent que de l'abstraction, comme s'ils poussaient toute la couche à plat. Après l'aplatissement, les clients interagissent avec le système de manière "égale". L'ajout de nouveaux clients est juste une entrée, une sortie et des formes de présentation différentes.C'est une autre architecture que nous sommes sur le point de comprendre, l'architecture hexagonale.
architecture hexagonale
Dans notre code, il existe de nombreuses dépendances externes directes et des détails d'implémentation. Tels que la classe mapper de mybatis, l'injection httpclient, la surveillance rocketmq, le fonctionnement direct du cache, etc. Ce type d'implémentation présente deux problèmes évidents : le premier est que lorsque les composants sous-jacents sont remplacés, cela aura un impact direct sur la logique métier, et la quantité de modifications de code et la portée des tests seront considérablement augmentées. Deuxièmement, il n'est pas propice à la réutilisation des fonctions : si d'autres entreprises ont une logique similaire, elles ne peuvent pas être directement transplantées et réutilisées.
En 2005, Alistair Cockburn a proposé l'architecture hexagonale, également connue sous le nom d'architecture de port et d'adaptateur. En observant la figure ci-dessus, nous avons constaté que pour l'application principale et le modèle de domaine, d'autres dépendances ou implémentations sous-jacentes peuvent être résumées en deux types : entrée et sortie. La relation organisationnelle est devenue une relation bidimensionnelle interne et externe, plutôt qu'une structure descendante. Avant chaque io et application, il y a un adaptateur pour terminer le travail d'isolation, et chaque bord le plus à l'extérieur est un port. Le système conçu sur la base de l'architecture hexagonale est la forme finale poursuivie par DDD. La pratique de l'architecture hexagonale est expliquée dans la section "DDD Advantages".
Après avoir d'abord donné la pratique basée sur l'architecture hexagonale, la structure du module de projet :
Conception tactique DDD
La conception tactique commence d'un point de vue technique, se concentre sur la réalisation technique du modèle de domaine et complète le développement et la mise en œuvre du logiciel, y compris la conception et la mise en œuvre de la logique de code pour les racines agrégées, les entités, les objets de valeur, les services de domaine, les services d'application et les ressources. bibliothèques .
Entité : Composée d'attributs et de comportements, elle possède un identifiant unique.
Lors de la conception de systèmes, nous avons tendance à nous concentrer sur les données plutôt que sur le domaine. Il en va de même pour les développeurs DDD, car dans le développement logiciel, les bases de données occupent encore une place prépondérante. La première chose à considérer est les attributs et les associations de données, plutôt que les concepts de domaine riches en comportement. Le résultat est que le modèle de données est directement reflété sur le modèle d'objet, ce qui donne des entités contenant uniquement des méthodes get/set, ce qui n'est pas une approche DDD.
Seule l'entité get/set doit être utilisée conjointement avec le service, et les coûts de cohésion, de maintenabilité et de réutilisation de la migration sont nettement plus élevés que l'approche DDD.
Objet de valeur : un objet qui n'a pas d'identité unique, qui est mesurable ou descriptif et qui satisfait l'invariance.
Nous devrions essayer d'utiliser des objets de valeur pour modéliser au lieu d'objets d'entité, car par rapport aux entités, nous pouvons créer, tester, utiliser, optimiser et maintenir des objets de valeur très facilement.
Service de domaine : un service de domaine représente une opération sans état utilisée pour implémenter une tâche spécifique à un domaine.
Lorsqu'une opération ne convient pas aux agrégats et aux objets de valeur, le meilleur moyen consiste à utiliser les services de domaine.
Par exemple "l'authentification de l'utilisateur", une façon est que nous pouvons simplement mettre l'opération d'authentification sur l'entité. Avec cette conception, il y a deux problèmes. Premièrement, la classe d'utilisateurs doit connaître certains détails d'authentification, et deuxièmement, cette approche ne peut pas exprimer explicitement le langage commun. On demande ici si un Utilisateur est "authentifié" sans exprimer la démarche d'"authentification". Dans la mesure du possible, nous devrions essayer d'exprimer directement le langage de communication en termes de modélisation.
Événements de domaine : certains événements qui se produisent dans le domaine et qui intéressent les experts du domaine. Nous utilisons généralement des événements de domaine pour maintenir la cohérence des événements, ce qui peut éliminer la validation en deux phases (transaction globale).
Agrégation : L'agrégation est une combinaison d'un groupe d'objets liés, accessible par le monde extérieur dans son ensemble, et la racine agrégée est le nœud racine de cette agrégation.
L'agrégation est un concept très important, et les zones centrales sont souvent exprimées en termes d'agrégation. Deuxièmement, l'agrégation a également une valeur technique très élevée, qui peut guider la conception détaillée. L'agrégat se compose de l'entité racine, de l'entité et de l'objet de valeur.
Usine : L'usine fournit une interface pour la création d'objets, qui encapsule tout le processus d'opération complexe de création d'objets, et en même temps, elle n'exige pas que les clients se réfèrent aux objets réellement créés.
Avantages du DDD
Le système appliquant DDD est conforme à l'architecture hexagonale, et nous atteignons les objectifs suivants :
Indépendant du framework : l'architecture ne doit pas dépendre d'une bibliothèque ou d'un framework externe, et ne doit pas être liée par la structure du framework ;
Indépendant de l'interface utilisateur : le style affiché au premier plan peut changer à tout moment, mais l'architecture sous-jacente ne doit pas changer en conséquence ;
Indépendant des sources de données sous-jacentes : l'architecture logicielle ne doit pas subir de changements drastiques en raison de différents magasins de données sous-jacents ;
Indépendance vis-à-vis des dépendances externes : quelle que soit la manière dont les dépendances externes sont modifiées ou mises à niveau, la logique de base de l'entreprise ne doit pas changer de manière significative en conséquence.
Références https://mp.weixin.qq.com/s/g_kvMHAkqiHyv1O5ZHADKQ
https://juejin.cn/post/7050738599649607694