Comprendre rapidement l'idée d'architecture de conception basée sur le domaine DDD - articles de base | Équipe technique logistique de Jingdong

1. Introduction

Cet article apprendra et présentera brièvement Domain Drive Design (DDD), pourquoi nous avons besoin de Domain Drive Design, ainsi que ses avantages et ses inconvénients. Essayez d'utiliser des mots faciles à comprendre pour décrire et expliquer Domain Drive Design. Il expliquera le mise en œuvre à partir de la discussion approfondie. Vous pouvez accéder à une étude et une discussion approfondies après avoir compris l'introduction ou dans les chapitres avancés et avancés de suivi. J'espère que grâce à l'introduction de cet article, vous pourrez rapidement comprendre DDD et avoir une cognition de base, DDD lui-même est un ensemble de théories. Il est difficile de mettre en œuvre efficacement DDD sans accumuler de théories. Il suffit de regarder quelques cas de code et de commencer à le faire. Ce qui ressort à la fin n'est qu'une simple imitation, alors ne le faites pas être trop ambitieux. Enfin, j'espère que chacun pourra réfléchir davantage dans son travail, par exemple à la manière de concevoir le projet dont vous êtes responsable si vous utilisez DDD et aux défis auxquels vous serez confronté.

Avant d'apprendre à comprendre DDD, j'espère que chacun pourra revoir ce que nous avons appris dans le passé et maîtriser certaines connaissances, et essayer de laisser s'installer le contenu que nous avons appris et maîtrisé. Je recommande de lire des séries.

• Modèles de conception tête première : concepts de base orientés objet et modèles de conception importants ;
• Base de modélisation orientée objet UML : des exigences à l'analyse, de l'analyse à la conception, de la conception au codage, UML est utile
• Réaliser une conception axée sur le domaine : lectures recommandées très épaisses, plus pragmatiques
• Domain-Driven Design : le travail pionnier de Zhang Yi-DDD est assez fantastique et il bénéficiera beaucoup de sa lecture plusieurs fois ;

2 Définitions et concepts

Domain Driven Design (DDD) propose un ensemble de méthodologies allant de l'analyse du système à la modélisation logicielle. Convertissez les concepts commerciaux et les règles commerciales en concepts et règles dans le système logiciel, réduisant ou masquant ainsi la complexité de l'entreprise et rendant le système plus évolutif pour traiter des problèmes commerciaux réels complexes et changeants. En résumé, il s'agit d'une méthode de conception complète et systématique, d'une sorte de design thinking, d'une méthodologie, et non d'une « architecture système », d'une sorte de principes et de réflexions de conception architecturale.

2.1. Pourquoi utiliser le « Domain Driven Design », ou quel est son objectif et son scénario d'application ?

1. Bon pour gérer le développement de produits d'entreprises très complexes, ce qui peut nous aider à affiner un noyau de produit stable (appelé domaine principal dans le modèle de domaine) ;

2. La modélisation peut améliorer la cohésion élevée de la modélisation, réduire le degré de couplage entre les modèles et améliorer l'évolutivité et la stabilité du système ;

3. Mettre l'accent sur la coopération et la communication entre l'équipe et les experts du domaine contribue à établir une organisation d'équipe bien communiquée ;

4. Les idées de conception et les spécifications de conception unifiées aident à améliorer les capacités de conception architecturale et les capacités de conception orientée objet des membres de l'équipe ;

5. Les constructions de microservices existantes suivent les principes architecturaux de la conception axée sur le domaine ;

6. Si le système logiciel dont vous êtes responsable n’est pas complexe, alors vous n’avez vraiment pas besoin d’apprendre le Domain Driven Design !

2.2. Quelle est la plus grande différence entre la conception axée sur le domaine et la pensée architecturale populaire actuelle ?

La pensée de la conception axée sur le domaine est la suivante : objet + comportement + service, et toutes les conceptions tournent autour des objets, des comportements et des services ;

La conception architecturale la plus répandue actuellement est la suivante : expansion verticale basée sur l'architecture en couches MVC et expansion horizontale des produits par modules métier ;

2.2.1. La solution traditionnelle

Architecture d'application à trois niveaux : présentation de l'application de données (couche de logique métier), généralement basée sur des bits de données pour l'analyse et la conception de la base de données.

1. La couche de service est trop lourde, le modèle de données perd du sang et il n'y a rien ;

2. Programmation de type Noodle ou programmation orientée base de données, la couche de service complète la logique métier autour des opérations de base de données, souvent sur une seule ligne jusqu'à la fin ;

3) Le code est trop lourd un par un, et il est difficile à développer et à réutiliser ;

4. Le modèle de base de données n'est qu'un mappage de base de données, sans support comportemental pertinent, et les comportements sont tous complétés par le service de couche supérieure, c'est donc un modèle de domaine qui perd du sang ;

2.2.2. Solution basée sur le domaine

L'architecture à quatre niveaux désassemble la logique métier de la couche à trois niveaux en couche d'application et la couche de domaine dans la structure en couches DDD, et transfère les performances de la logique métier de base vers la couche de domaine pour la réalisation, avec le modèle de domaine métier comme élément principal. modélisation de base (modélisation orientée objet), qui peut mieux refléter l'abstraction du monde réel, et ses avantages sont les suivants

1) Couche de service légère + modèle de domaine hyperémique ;

2. Le modèle de domaine encapsule et implémente son propre comportement, qui peut être considéré comme un composant à haute cohésion et à faible couplage ;

3. Étant donné que le modèle intègre des données et des comportements, il s'agit d'un objet explicite avec une grande réutilisabilité du code et une logique métier claire ;

• Couche d'interface utilisateur : la responsabilité principale est d'afficher les informations sur les données à l'utilisateur via l'interface utilisateur, d'expliquer la commande de l'utilisateur en même temps et d'envoyer la demande de l'utilisateur à la couche application.
• Couche d'application : Terminez l'exploitation des ressources de données et l'arrangement des processus métier en appelant les paramètres de base et la couche de domaine, qui est équivalente à la couche BS ;
• Couche de domaine : la logique métier est très cohérente avec la couche de domaine, de sorte que la couche de domaine est le cœur de l'ensemble du système, elle n'est liée qu'à l'activité réelle, ne se soucie d'aucun détail technique et n'a rien à voir avec la persistance. autant que possible;
• Couche infrastructure : contient tout type de framework, code d'accès à une base de données ou méthodes publiques, etc., une couche de technologie pure ;

2.3 Comment apprendre la conception axée sur le domaine

Personne ne peut réaliser une conception axée sur le domaine du jour au lendemain. Ce que l'on appelle « relier la théorie à la pratique », lors du premier contact ou de l'apprentissage de la conception axée sur le domaine, il y aura toujours un appel à donner des directives ou des spécifications de conception sous forme de formule. Il semble que La conception de logiciels est comme des blocs de construction, tant que vous suivez le processus de construction illustré dans le diagramme, vous pouvez construire le modèle attendu sans réfléchir. Cela semble un fantasme irréaliste. Pour maîtriser la conception axée sur le domaine, vous devez d'abord comprendre et maîtriser certains concepts et connaissances théoriques, sur cette base, en réfléchissant aux principes derrière ces concepts, aux principes de conception et en réfléchissant à la division des limites du contexte délimité (Contexte limité), en fait, c'est toujours l'incarnation du principe de « haute cohésion » et faible couplage", mais quel contenu considérons-nous comme la cohésion élevée, comment faire abstraction pour obtenir un faible couplage, comment coopérer entre les couches dans une architecture en couches ? La manière de découpler les dépendances est apparue, et les décisions de conception doivent encore être considérées dans la perspective de la réutilisation et du changement.

3. Conception basée sur le domaine

La conception pilotée par domaine met l'accent sur le « domaine » comme force motrice principale et garantit la cohérence entre le modèle de domaine et la conception du programme grâce à une conception pilotée par modèle. Le modèle de domaine ne doit contenir aucun facteur de mise en œuvre technique. Les objets du modèle expriment véritablement le Concept de domaine, mais pas Contraint par la mise en œuvre technique, le modèle de domaine lui-même n'a rien à voir avec la technologie et la conception axée sur le domaine est divisée en conception stratégique et conception tactique.

• Un domaine est composé d'un ou plusieurs modèles ;
• Un modèle est par définition une abstraction d’un domaine ;
• D'après la compréhension, le modèle général peut être considéré comme un composant, un module ou un sous-domaine à haute cohésion et à faible couplage ;
• Le modèle se concentre sur le processus de modélisation, qui fera abstraction d'une série d'objets de domaine et de services de domaine ;
• Dans DDD, une série d'« éléments de domaine » standard sont définis pour la modélisation de domaine ; comme le métamodèle de conception tactique.

3.1. Conception de la stratégie

Insistez sur les points clés de la stratégie commerciale, comment répartir le travail en fonction de son importance et comment faire de son mieux, suivez le principe de grande quantité :

1. Les décisions de conception doivent être guidées de manière à réduire les interdépendances entre les pièces, en utilisant plus clairement l'intention de conception sans perdre l'interopérabilité et la systémique essentielles ;

2. Le modèle doit se concentrer sur la capture du noyau conceptuel du système, la « vision » du système.

3.1.1 Division des sous-domaines

Une partie du domaine commercial dans son ensemble, centrée sur le macro-business et divisant le vaste domaine en divisions conceptuelles plus petites entre les entreprises, facilite la prise de décision sur la manière d'allouer les ressources (personnes, argent) pendant la phase de planification du système.

1) Sous-domaine principal : la partie la plus précieuse et la plus centrale du domaine, la clé du succès ou de l'échec du produit et la compétitivité de base. Dans le développement de DDD, concentrez-vous sur le domaine principal et accordez-lui la plus haute priorité ;

2. Sous-domaine de support : fonctions associées qui prennent en charge le sous-domaine principal du projet, en se concentrant sur un certain côté opposé de l'entreprise ;

3. Sous-domaine général : un sous-domaine cohérent qui n'a rien à voir avec l'intention du projet, pour résoudre certains problèmes généraux, et aucune activité propriétaire ne doit être placée dans le sous-domaine général ;

3.1.2. Modélisation de la stratégie

L'accent est mis sur la division physique du système. En fonction des résultats de votre segmentation de domaine et de la structure organisationnelle de l'entreprise ou du service, vous décidez comment diviser les sous-systèmes, par exemple comment les diviser et comment interagir les uns avec les autres. Ce niveau ne comporte souvent pas suffisamment de détails techniques pour le moment.

1) Contexte limité (Bounded Context) : de manière générale, il fait référence aux modules du système, aux sous-services de l'architecture des microservices et au "package (Java)" ou espace de noms (C#) dans le monomère. est une division physique du système et limite le domaine. La limite du modèle est introduite à un niveau plus profond. Cette chose est divisée en deux mots : limite et contexte. On peut comprendre qu'au début de la conception du système, vous avez besoin pour tracer un cercle et définir une plage pour garantir que le modèle de domaine est limité à l'intérieur de ce cercle et ne peut pas être traversé. champ, ce « cercle » est le contexte délimité.

2. Langage commun : il est utilisé pour unifier le langage utilisé par les experts dans le domaine, les produits, la recherche et le développement et les tests afin d'éviter des problèmes tels qu'une incohérence dans la compréhension des exigences, une incohérence entre la conception et les exigences et une mauvaise communication. les uns par rapport aux autres, la scène est différente, le même mot aura des significations différentes.

3. Carte de contexte : utilisez des graphiques pour exprimer la relation entre les contextes délimités, et la carte de contexte sera présentée en détail plus tard, comme les partenariats, les couches anticorrosion, les grosses boules de boue, etc. ;

3.2. Conception tactique

En fonction du modèle de domaine et de l'oracle général, les concepts du modèle de domaine et de l'oracle général sont mappés à l'implémentation du code via le modèle technique. À mesure que le modèle évolue, l'implémentation du code sera également remaniée pour mieux refléter le concept du modèle.

• comprennent principalement :

1. Représenter des concepts dans le domaine, tels que des entités, des objets de valeur, des services de domaine, des modules, etc. ;

2. Utilisé pour gérer le cycle de vie des objets. Tels que les agrégats, les usines, les entrepôts, etc. ;

3. Pour l'intégration ou le suivi, comme les événements de domaine, etc. ;

3.3. Explication des termes

1. Domaine/Sous-domaine : Quel domaine ? Au sens large, un domaine est ce que fait une organisation et tout ce qu'elle comprend. Le domaine peut être grand ou petit, et il existe des limites, non infinies, comme le commerce électronique, le trading, les achats, etc. Par exemple, nous avons souvent entendre les clients dire « Nous avons quelques secteurs d'activité ». D'une manière générale, ce qu'on appelle « plusieurs éléments » fait ici référence à des sous-domaines.

2. Entité : Ce mot est largement utilisé par nous, voire galvaudé. L'entité est un concept important. Une entité typique doit avoir 3 éléments (identité, attribut, comportement de domaine), doit avoir une identité unique, pas d'identité. Un objet de domaine identifié n'est pas un entité. Tel que : L’objet utilisateur est une entité.

3. Attributs : les attributs d'une entité sont utilisés pour décrire les caractéristiques statiques du sujet et contenir des données et un état.

@Data
public class Product{
    private String sku;
    private String name;
    private Price price;
}

4. Comportement de domaine : une entité possède un comportement de domaine qui décrit mieux sa dynamique en tant que sujet. Un objet qui n'a pas de caractéristiques dynamiques n'appartient pas au domaine de comportement.

@Data
public class Product{
    private String sku;
    private String name;
    private Price price;

    //变更状态的领域行为
    public void changePriceTo(Price newPrice){
        //设计产品新加个
        .......
        
    }
}

5. Objet de valeur (objet de valeur) : il est relativement abstrait, généralement en tant qu'attribut d'une entité. La différence entre un objet de valeur et une entité est qu'un objet de valeur est immuable et n'a pas d'identifiant unique. Il est uniquement défini par la valeur de son attribut, et la participation est son jugement est basé sur la valeur ou l'identité, le premier est un objet de valeur et le second est une entité ;

Un petit exemple : la relation entre les articles de commande et les commandes : plusieurs à un, il y a plusieurs articles de commande dans une commande, et un article de commande n'apparaîtra que dans une seule commande. Relation de combinaison, certaines parties ne peuvent pas exister séparément du corps principal.

public class Order {
    int id;
    User user;
}

public class OrderItem {
    private int id;
    private Product product;
    private int num;
    private Order order;
}

6) Racine d'agrégat : Dans l'agrégat, une entité doit être désignée comme racine d'agrégat pour servir de choc externe à l'ensemble de l'agrégat, c'est-à-dire que l'extérieur ne peut accéder aux objets internes que via la racine d'agrégat. les restrictions peuvent maximiser les objets internes Protect.

4 Quelle est la valeur

Le développement de presque tous les projets a une telle règle : les exigences initiales sont simples et la complexité du système est améliorée en raison de l'augmentation de l'activité aux stades intermédiaire et avancé, ce qui conduit à la nécessité d'une réforme radicale de la conception originale. Par conséquent, plus le système est complexe et plus la taille du code est grande, plus les avantages du DDD sont importants.

• Communication coopérative : mettre l'accent sur la communication coopérative entre l'équipe et les experts du domaine, ce qui contribue à établir une organisation d'équipe bien communiquée ;
• Pensée unifiée : l'unification de la pensée de conception et des spécifications de conception contribue à améliorer les capacités de conception architecturale et les capacités de conception orientée objet des membres de l'équipe ;
• Système flexible : grâce à la modélisation, la cohésion élevée du modèle peut être améliorée, le degré de couplage de la construction du modèle peut être réduit et l'évolutivité et la stabilité du système peuvent être améliorées ;
• Noyau de produit : bon pour gérer le développement de produits commerciaux de haute complexité, ce qui peut nous aider à affiner un noyau de produit stable ;
• Précipitation commerciale : le modèle de domaine est le cœur du système et la précipitation directe des activités dans le domaine, ce qui a une grande valeur commerciale.

5 Conclusion du chapitre de base

Une base théorique importante pour la division des microservices est la conception axée sur le domaine. Cependant, en raison du seuil élevé de DDD, de nombreux concepts, de systèmes vastes et abstraits et du manque d'expérience et de cas pratiques, de nombreux développeurs ont beaucoup de doutes sur DDD, ou seulement rester dans le Je m'appuie généralement sur les recherches ou les collègues autour de moi pour parler de DDD. Grâce à cet article, j'ai une compréhension préliminaire de la conception axée sur le domaine. Au début, nous le présenterons brièvement ici. Plus tard, nous partagerons DDD au niveau du code pour l'implémenter.

Auteur : JD Logistics Bian Lei

Source : Réimprimé de Yuanqishuo Tech par la communauté des développeurs JD Cloud, veuillez indiquer la source

L'élève de troisième année du secondaire a écrit la version Web de Windows 12 deepin ." -IDE qui a officiellement fait ses débuts, connue sous le nom de "recherche et développement véritablement indépendants "Père de Hongmeng" Wang Chenglu : Le système de version Hongmeng PC sera lancé l'année prochaine et Wenxin sera ouvert à l'ensemble de la société .Officiellement publié 3.2.0 Green Language V1.0 Officiellement publié

{{o.name}}

{{m.nom}}