Pratique DDD pour l'équipe de robots téléphoniques

Introduction

DDD est un ensemble de méthodologie et un ensemble d'idées. Une grande variété de métamodèles et de concepts nominaux. Leur essence est « l’une » des solutions correspondant à l’idéologie directrice, et les débutants se laissent facilement piéger par l’apparence. Vous devez toujours garder clairement à l'esprit que "tous les métamodèles DDD sont créés pour résoudre certains types de problèmes dans le développement réel". Lorsque vous entrez en contact avec divers métamodèles, vous devez effectuer une vérification basée sur les problèmes rencontrés par votre propre entreprise. Cela vous aidera à éviter de vous laisser piéger par des représentations conceptuelles et à revenir à l'essence de la résolution des problèmes.

Contexte

L'équipe d'architecture de données a commencé à développer le robot téléphonique guidé par les besoins de l'entreprise en 2018, et cela fait près de 5 ans en un clin d'œil. À l'heure actuelle, plus de 100 types différents de robots ont été construits sur cette plate-forme pour fournir des capacités d'appels sortants aux concessionnaires de l'entreprise, aux voitures d'occasion, aux équipementiers, aux services financiers et aux autres activités des BU, avec des centaines de milliers d'appels sortants par jour. Le projet de robot téléphonique a commencé à prendre forme, mais il a également rencontré de nombreux défis au cours du processus. Afin de faire face à ces défis, notre équipe a finalement adopté la pensée DDD pour la reconstruction et le développement.

Dans le processus d'application de DDD, l'équipe d'architecture de données a mis en œuvre certaines de ses propres spécifications de développement. J'aimerais ici partager quelques expériences et idées avec vous, en espérant qu'elles puissent servir de point de départ. Laissez-moi vous expliquer ici. De nombreux modèles multivariés ne sont pas abordés dans cet article et aucun cas spécifique n'est présenté. Considérons d’abord la question de la longueur. La seconde est de comprendre l'idée du DDD et de la mettre en œuvre en combinant les activités respectives. Il n'est pas pertinent de donner des exemples dans mon entreprise. De plus, de tels cas sont faciles à trouver. En même temps, je pense qu'il serait plus précieux que chacun partage les problèmes et les solutions rencontrés par notre équipe, le processus de mise en œuvre et les spécifications de développement que nous avons formées. Les étudiants intéressés par DDD, souhaitant en savoir plus ou ayant des questions sur cet article sont invités à me contacter pour en discuter.

Ci-dessous, je partagerai à partir de ces parties : les défis rencontrés dans le projet de robot, pourquoi DDD est DDD, les étapes pour mettre en œuvre DDD, les améliorations de l'équipe, les conflits rencontrés de la théorie à la pratique ainsi que les améliorations futures et des résumés dans les applications DDD.

1. Défis rencontrés

Défi 1 : Grande complexité de la logique métier. Avec l'accès à divers services, une nouvelle logique est constamment ajoutée pour gérer des services spécifiques dans différents scénarios.

Tels que : logique de reconnaissance d'intention dans le processus.

La reconnaissance d'intention nécessite l'identification de plusieurs modèles d'IA. Les intentions reconnues par plusieurs modèles peuvent entrer en conflit et des règles de configuration d'intention contradictoires doivent être choisies. Dans le même temps, pour certains scénarios de démarrage à froid ou d’optimisation d’urgence, il est nécessaire de prendre en charge l’identification des intentions en configurant des règles pour qu’elles prennent effet en temps réel. Et les emplacements de mots correspondants doivent être pris en charge dans la reconnaissance intentionnelle des règles. Il existe de nombreux types d'emplacements de mots. Les emplacements de mots globaux avec scénarios et les emplacements de mots avec processus se distinguent en termes de priorité. À partir de la source d'identification des données, elles peuvent être divisées en celles identifiées par l'IA, celles correspondant à des règles de dictionnaire ou celles transmises par l'entreprise. Une fois l'activité réalisée pendant un certain temps, différents attributs sont ajoutés aux différents types d'emplacements. Par exemple, les emplacements pour les séries de voitures incluent le produit, la portée de l'activité, la non-exploitation, etc. 🎜# Défi 2 : La structure de l'architecture du code n'est pas claire . À mesure que les exigences métier s’ajoutent, la taille du code augmente. Couplées à la complexité de la logique et aux différents codes des développeurs d'équipe, les différentes frontières logiques deviennent progressivement confuses.

Par exemple : notre méthode de développement habituelle consiste à le démonter en fonction de modules fonctionnels, et le processus métier est connecté en série pour coordonner chaque module afin de compléter conjointement les exigences métier. Cependant, face à la logique complexe de ce type d'entreprise, cette conception de solution présente de grands inconvénients et les limites des modules sont facilement franchies.

Les relations entre les modules s'appellent les uns les autres. La conception originale de l'isolation des modules a en fait été complètement rompue lors du processus de mise en œuvre. Les modules divisés verticalement, initialement idéaux, deviennent une structure en forme de maillage.

Les attributs ou méthodes développés par le responsable du module au stade intermédiaire dépendent d'autres modules externes, ce qui entraîne une divergence des fonctions. Cela entraîne des risques accrus lorsque les exigences changent ultérieurement, ou lorsqu'il peut s'avérer que les méthodes qui peuvent être modifiées à volonté ne peuvent pas être modifiées et qu'un code logique supplémentaire doit être ajouté pour l'implémenter. Cela rend un code déjà complexe encore plus complexe.

Le démantèlement des exigences commerciales est déraisonnable. Les fonctions requises sont développées à proximité lors de la mise en œuvre, et le démontage des modules n'est pas strictement suivi, et il y a un manque de réflexion unifiée comme orientation.

Défi 3 : Il y a tellement de demande pour le produit qu'il est difficile de dire s'il a une réelle valeur.

Défi 4 : La logique change rapidement et de nombreuses demandes nécessitent une refonte de la logique du code.

Défi 5 : Il existe de nombreuses entreprises, des descriptions incohérentes de chaque entreprise et des coûts de communication élevés.

Les frontières verticales sont brisées, la complexité du code augmente et les processus métier sont fréquemment ajustés. Ces multiples dimensions se superposent, rendant le développement et la maintenance exponentiellement plus difficiles. La stabilité du système d'application de premier niveau du robot téléphonique est difficile à garantir. Même si les camarades techniques sont tous des ingénieurs seniors, ils ont conçu selon les idées du microservice qu'ils peuvent comprendre et désassemblé le projet en fonction des modules. Même si la logique du code a cité de nombreux modèles de conception à construire et à développer, même s'il a été connecté. dans différentes parties de l'entreprise, outils qualité de la plateforme, rédaction de nombreux tests unitaires. Cependant, lorsque le projet itérait sur de nouvelles exigences, de nombreuses « surprises » apparaissaient encore, provoquant des maux de tête pour toute l'équipe.

2. Pourquoi DDD

Pourquoi DDD ? Il y a tellement de piles technologiques et tellement d'idées chaque jour, pourquoi DDD est-il utilisé pour les gérer ? Tout d'abord, DDD modifie très bien « comment gérer la complexité fondamentale des logiciels », ce qui donne envie à de nombreuses personnes de le découvrir. Voyons donc comment DDD résout les défis rencontrés dans le projet.

Tout d’abord, examinons la classification de la complexité de DDD et voyons si la complexité à laquelle DDD doit faire face est un défi auquel je suis confronté. Dans les documents liés au DDD, les causes de la complexité sont explorées et analysées à partir des deux dimensions de la capacité de compréhension et de la capacité de prédiction.

Capacité de compréhension (c'est-à-dire que le système logiciel est complexe et difficile à comprendre pour les développeurs) :

Première échelle : Le premier facteur qui affecte la capacité de compréhension. Il existe des centaines de millions de lignes de code et la relation entre chaque point de demande s'influence mutuellement. Modifier une zone affectera tout le corps.

Deuxième structure : une structure déraisonnable, voire déroutante, rend difficile la maintenance des fonctions pour les développeurs.

Capacité prédictive (c'est-à-dire que le développement de l'entreprise est difficile à prédire) :

Lorsque les exigences changent, il est difficile de prédire la direction de la mise en œuvre du logiciel, et des problèmes de sur-conception et de sous-conception se produiront. Lors de la conception excessive, de nombreuses interfaces ont été réservées et de nombreux modèles ont été construits pour augmenter la complexité de mise en œuvre du code, mais il s'est avéré plus tard qu'ils n'étaient pas utilisés. La conception est insuffisante et la réalisation des exigences ne tient pas compte du développement ultérieur. Lorsque des changements surviennent, la conception existante doit être renversée et redéveloppée. Les produits se plaignent de faibles capacités de conception.

Les causes de la complexité dans DDD sont résumées comme suit : l'échelle, la structure et le changement ; l'échelle et la structure créent des obstacles à la compréhension, les changements créent des obstacles à la prédiction, et les deux s'additionnent pour former un problème de complexité.

Deuxièmement, DDD n'est pas seulement une théorie de la phase de conception de code, mais comprend également des conseils de conception complets depuis l'analyse des exigences, la cartographie de l'architecture, la modélisation et la mise en œuvre.

Au stade de l'analyse de la demande, nous pouvons comprendre avec précision la valeur commerciale à l'avance grâce à une idéologie directrice pertinente et capturer l'orientation des changements futurs. Au cours de l'étape de cartographie de l'architecture, l'idéologie directrice du processus allant des exigences à l'architecture est donnée, et le poids de la conception et les spécifications sont ajoutés. Grâce à la division des sous-domaines, à la superposition du système et à la classification métier à contexte limité, des spécifications d'orientation sont fournies pour garantir la clarté de l'architecture du système et réduire la complexité du système. Au cours de la phase de modélisation et de mise en œuvre, des métamodèles liés à la conception axés sur le domaine sont fournis pour clarifier la division fonctionnelle de chaque pièce et répondre rapidement aux besoins de l'entreprise et aux futurs changements fonctionnels.

Encore une fois, revenons à l’idéologie directrice donnée par DDD :

Problème d’échelle : briser les frontières. Divisez et conquérez le démontage avec des sous-domaines et des contextes délimités.

Compte tenu de l'idée de diviser pour régner, DDD fournit deux méta-modèles de conception importants : le contexte délimité et la cartographie du contexte.

Problèmes structurels : architecture en couches + isolation limitée.

La superposition peut isoler les problèmes de logique métier et de complexité de mise en œuvre technique. L'architecture en couches introduite par DDD encapsule la logique métier dans la couche de domaine et place l'implémentation technique qui prend en charge la logique métier dans la couche infrastructure. La couche d'application située au-dessus de la couche de domaine encapsule les services d'application et relie les deux pour la collaboration.

Problèmes de modification : concevez les modifications de manière proactive.

Les changements ne peuvent pas être contrôlés, nous ne pouvons que les accepter. Au cours de la phase d’analyse de la demande, la réflexion 5W est utilisée pour identifier les modèles de changement et contrôler les changements commerciaux. DDD utilise des métamodèles de conception pilotés par modèle pour modéliser le domaine des contextes délimités, formant ainsi un modèle de domaine qui combine l'analyse, la conception et la mise en œuvre.

Enfin, regardons la solution proposée par DDD. Il introduit un ensemble de métamodèles de conception affinés en modèles, permettant aux logiciels d'entreprise de contrôler l'échelle, de diviser les structures et de répondre de manière proactive aux changements.

Laissez-moi vous présenter brièvement cette photo, qui est divisée en deux parties. La première partie est la partie entourée de points ci-dessous et ne nécessite pas de mise en œuvre technique particulière. Certaines solutions de méta-modèle pour traiter l'espace du problème sont mises en œuvre pendant la phase d'analyse des exigences. Dans l'autre partie, sur la base de la première partie, nous effectuerons la superposition spécifique de l'architecture du système, l'abstraction et l'agrégation des objets, ainsi que le désassemblage des services. À ce stade, nous mettrons en œuvre la conception correspondante.

Ma compréhension est la suivante. Ce métamodèle de conception fournit une solution complète depuis l'analyse de la demande, la conception et la mise en œuvre. Démantèlement du système lors de la phase d'analyse des besoins (correspondant au méta-modèle de sous-domaine de la figure). Ensuite, divisez-le dans le contexte limité de la granularité des mises à jour. Et le schéma de relation collaborative de chaque frontière est donné (correspondant au méta-modèle de cartographie contextuelle de la figure). La phase de mise en œuvre de la conception fournit le plan des éléments de conception de la conception pilotée par modèle, à travers la conception granulaire de l'architecture hiérarchique du système, des services de domaine, de l'agrégation, etc. Fournir un ensemble de solutions complètes, théoriquement soutenues, réalisables et standards.

L'analyse DDD ci-dessus et le positionnement de la complexité du problème sont complètement le problème du système de robot téléphonique. Les solutions proposées résolvent également parfaitement les différents défis auxquels l’entreprise est confrontée. Après avoir réalisé sa valeur, l’équipe est rapidement parvenue à un consensus pour la mettre en œuvre dans les projets ultérieurs.

3. Étapes de mise en œuvre de DDD

Je n'entrerai pas dans les détails des détails du méta-modèle et des limites commerciales, mais je donnerai directement les étapes et les produits réels de notre équipe.

3.1 La première étape de la phase de pré-recherche

Notre expérience dans cette partie est qu'un membre de l'équipe agit comme un précurseur, dépensant d'abord son énergie pour une étude approfondie des concepts liés au DDD, puis en la synchronisant avec l'ensemble de l'équipe. . Pour notre équipe, la phase de recherche est fragmentée et il est difficile d'estimer combien de temps elle prendra. La phase de vulgarisation scientifique en équipe a duré 4 fois et a duré 8 heures. Après cela, les étudiants de l’équipe ont la capacité d’apprendre rapidement et en profondeur sur la base de conseils conceptuels. Et organisez les membres de l’équipe pour qu’ils discutent entre eux pour confirmer leur compréhension.

3.2 La deuxième étape consiste à introduire l'idéologie directrice et les spécifications de mise en œuvre

3.2.1 Dans la phase d'analyse de la demande, le support théorique du modèle 5W est introduit pour aider à identifier les besoins réels, contrôler activement la direction du changement et éliminer des besoins dénués de sens.

Cette partie est la théorie 5W comme support théorique pour analyser les besoins des produits. Elle est très utile pour identifier les besoins réels et mieux analyser l'orientation de développement de l'entreprise. Les exigences non valides peuvent également être réduites à partir de la source, directement comme indiqué dans l'image ci-dessus.

3.2.2 introduit les spécifications de service et implémente les fonctions commerciales avec des codes de comparaison basés sur des documents. Il est utile pour le développement et le tri des exigences ultérieures, et peut également être utilisé comme facteur de couverture des tests unitaires.

• 3.2.2.1 Le consensus parmi les membres de l'équipe est que la spécification du service doit d'abord être écrite, puis développée. Le temps passé à rédiger la spécification du service consiste en fait à trier la compréhension technique des exigences et à clarifier les idées. Cette partie du temps peut être récupérée lors de l'écriture du code ultérieurement.
• 3.2.2.2 Spécifications et exigences du service. Les spécifications du service correspondent à l'essai unique. En passant, cela résout le problème qu'il n'y avait pas de norme pour les tests uniques auparavant (la couverture du code et des méthodes que je comprends ne peut pas être appelée des normes).

Voici le modèle de cahier des charges de service adopté par notre équipe :

Numéro : Un numéro unique qui marque le service métier.

Nom : nom du service commercial sous forme de phrase verbale.

Description :

述 述 Je souhaite

faciliter le déclenchement des événements :

L'événement de service métier qui a déclenché activement le personnage peut être un clic du contrôle de l'interface utilisateur, une stratégie spécifique ou un système compagnon envoyé par le système système. Nouvelles, etc.

Processus de base :

Utilisé pour exprimer le processus principal des services métier, c'est-à-dire le scénario commercial d'une exécution réussie. On peut également l’appeler le « scénario principal de réussite ».

Processus alternatif :

Processus étendu utilisé pour exprimer des services métier, c'est-à-dire des scénarios commerciaux où l'exécution échoue.

Critères d'acceptation :

Une série de conditions ou de règles commerciales acceptables, répertoriées sous forme de puces.

3.3 La troisième étape consiste à déterminer la solution architecturale

Apprenez la solution du métamodèle de conception pilotée par modèle dans DDD. L'objectif principal est de diviser les limites des responsabilités, c'est-à-dire le contexte délimité, de transformer la relation traditionnelle de structure de réseau en une relation de segmentation verticale et de réduire la dépendance mutuelle. L’utilisation globale d’un démontage limité de textes en ligne et d’une conception de lecteur de diamant constitue l’orientation idéologique globale. Le système adopte une architecture en couches COLA 4.0

3.4 La quatrième étape est la norme de dénomination consensuelle pour former les spécifications de codage de l'équipe

Dénomination des packages consensuels, dénomination des classes, contrats de message pour les paramètres d'entrée et de sortie au sein de l'équipe et autres spécifications . Ce que je veux dire ici, c'est qu'il n'y a pas de norme de référence. J'espère que tout le monde pourra d'abord comprendre l'idée de DDD, puis se référer au système de dénomination qui fait l'objet d'un haut consensus dans l'industrie. Dans le même temps, vous devez prendre en compte les préférences de style de programmation des membres de l'équipe et, en fin de compte, formuler les normes de codage de votre propre équipe.

À titre d'exemple basé sur la dénomination de nos messages d'entrée et de sortie. Après avoir examiné toutes les parties, nous n’avons pas adopté la méthode de dénomination particulièrement fine présentée ci-dessus. Au lieu de cela, le consensus simple au sein de l’équipe est que le paramètre d’entrée *demande, le paramètre de sortie *réponse est la norme de dénomination.

3.5 La cinquième étape consiste à identifier le contexte délimité en fonction des caractéristiques de l'entreprise

Sur la base de l'idée DDD, mener une tempête d'événements sur l'entreprise, mener une analyse des exigences globales et une conception de cartographie de l'architecture sous la direction d'un langage unifié, et identifier les contexte délimité de l’entreprise.

Les étudiants en technique le conçoivent en fonction de leur propre entreprise. Il est relativement facile de le trouver en se référant aux informations de la démo, je n'entrerai donc pas dans les détails ici. Voici un processus d'orientation pour identifier un contexte délimité, le processus de cartographie en forme de V.

3.6 Entre enfin dans la phase de mise en œuvre de la modélisation

Il est recommandé d'utiliser le développement piloté par les tests pour le codage, c'est-à-dire en utilisant des pilotes rouges, verts et jaunes

Cette méthode suit ses trois lois, ce qui peut améliorer la compréhension des exigences. Problèmes de sous-conception et de sur-conception.

# 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 # Law One # 🎜🎜 ## 🎜🎜 ## 🎜🎜 # # Écrivez un seul test échoué à la fois pour décrire la nouvelle fonctionnalité. Law TwoN'écrivez aucun code produit à moins C'est juste assez pour réussir le test qui a échoué. Loi TroisSeulement si tous les tests sont réussis Faites le code refactoriser ou commencer à ajouter de nouvelles fonctionnalités.

4. Améliorations de l'équipe

4.1 De la réception passive des besoins à la réponse active

Lors de la phase d'analyse des besoins, utilisez le principe 5W. Analyser la rationalité des demandes et être en mesure de contrôler de manière proactive l'évolution de la direction du projet. Résolvez le « troisième défi » pour identifier la valeur de la demande et améliorez le « défi quatre » pour contrôler la direction des changements de développement commercial.

4.2 Réduire les coûts de communication

Utiliser un langage unifié et une communication idéologique pour réduire les coûts de collaboration dans tous les aspects du « Challenge Five ».

4.3 Amélioration de la conception de l'architecture

Démanteler raisonnablement la taille du code en concevant le modèle de sous-domaine et le contexte délimité du méta-modèle. Grâce à la réflexion en couches de DDD, la complexité de la logique métier et des dimensions techniques est isolée et la structure du code est claire. Dans le même temps, le projet adopte une structure symétrique en forme de losange et interagit avec l'extérieur par des passerelles nord-sud pour éviter l'apparition d'un réseau de modules. Résolution du problème du « Challenge 2 » et réduction de la complexité du « Challenge 1 ».

4.4 Amélioration de la mise en œuvre technique

Lors du développement des fonctions commerciales, l'équipe prendra en compte les limites raisonnables des exigences. Au cours du processus de mise en œuvre, nous déterminerons s'il convient de le placer dans la couche de domaine ou dans la couche de services métier, et s'il convient d'utiliser un modèle d'anémie ou un modèle de congestion pour implémenter les fonctions.

4.5 Amélioration des spécifications des documents

En termes de spécifications des documents, le mécanisme de spécification des services est introduit. Il peut être utilisé comme outil pour trier les exigences et comme base pour des tests uniques. Parallèlement, des documents de description de service sont également fournis pour une utilisation ultérieure.

4.6 Amélioration de l'implémentation du code

En termes d'implémentation du code, de l'architecture à l'implémentation du codage et à la dénomination, un ensemble de spécifications marquées a été formé.

De manière générale, sous ce mode, la façon de penser de l'équipe a changé. En appliquant divers méta-modèles, nous pouvons relever les défis posés par différents aspects, de l'analyse de la demande à l'architecture du système et à la mise en œuvre du code.

5. Conflits rencontrés de la théorie à la pratique

5.1 Modèle d'anémie Modèle de congestion PK

Modèle d'anémie : En termes simples, il s'agit d'une classe de données pure dans laquelle l'objet de domaine n'a que des méthodes getter/setter pour les attributs, et les deux métiers la logique et la logique d'application sont placées dans la couche de service, l'objet de domaine sous ce modèle est appelé « objet de domaine anémique » par Martin Fowler.

Modèle de congestion : Au contraire, le modèle de congestion contient non seulement les propriétés de l'objet, mais aussi le comportement de l'objet, y compris la logique métier.

D'un point de vue orienté objet, les objets contiennent des attributs et des comportements, le modèle de congestion doit donc être utilisé, et DDD recommande également d'utiliser en principe le modèle de congestion. Mais en ce qui concerne l'état de développement spécifique, même si le modèle de l'anémie présente de nombreux problèmes, il est dans l'industrie depuis de nombreuses années et est si couramment utilisé, et il a toujours sa valeur. De plus, la plupart des applications JAVA utilisent la pile technologique Mybatis, et de nombreux objets sont des entités anémiques générées automatiquement par des plug-ins. La question est donc : adopter le modèle de l’hyperémie signifie abandonner certains outils pratiques. Il y a de grandes divergences au sein de l’équipe sur cette question. En fin de compte, notre approche est qu’il n’existe pas de norme stricte pour cette partie, mais il est recommandé d’utiliser le mode hyperémie.

5.2 Respecter strictement les contraintes de conversion de données

PK utilise directement les données externes rationalisées et efficaces

Dans l'idée de DDD, afin d'assurer la fiabilité des services de domaine. Les données sur lesquelles s'appuient les services de domaine doivent être des entités et des données agrégées dans le domaine, et l'utilisation directe de données de contrat de message externe n'est pas autorisée. Correspondant à l'architecture symétrique en diamant, la conversion des passerelles nord-sud pour obtenir des données entraînera une charge de travail supplémentaire. Certains membres de l'équipe ont suggéré que certaines structures relativement stables n'ont pas besoin de se conformer à ce principe, car cela peut augmenter la vitesse de développement, et ils pensent que 90 % des données peuvent être des ressources avec des structures relativement stables telles que des bases de données. Mais en fin de compte, l’équipe était toujours strictement tenue de respecter cette idéologie directrice.

5.3 Le traitement du cache permet l'isolation des limites PK partagées

Traitement du cache dans différentes limites du même système : permet l'isolation des limites PK partagées.

À en juger par le scénario de l'époque, autoriser le partage peut réduire une certaine charge de travail et économiser des ressources à court terme. Mais la raison pour laquelle nous devons tracer des limites est de briser la relation et d’éviter qu’elle ne devienne trop importante. La suggestion donnée ici est de commencer par déterminer s’il est raisonnable de fusionner les services qui partagent des données en une seule frontière. Si la fusion n'est pas possible, les données doivent être isolées.

5.4 La spécification du service compare le front-end PK back-end des exigences

L'idée théorique directrice est très belle et elle est nécessaire pour protéger la réflexion sur la mise en œuvre technique lors de l'analyse de la demande. Mais après tout, cela doit être mis en œuvre dans la pile technologique. En ce qui concerne la mise en œuvre de la technologie, la mise en œuvre de la technologie interférera. L’un des problèmes majeurs à l’époque était que la mise en œuvre des fonctions pouvait être placée en front-end ou mise en œuvre en tant que service back-end.

Exemple 1 : L'exigence nécessite l'affichage de la combinaison "id+name", mais les deux champs d'id et de nom renvoyés par l'interface back-end sont combinés par la pile technologique frontale réelle et les spécifications de service pour le front-end. la fin et le back-end sont incohérents.

Exemple 2 : L'exigence nécessite de vérifier que le paramètre n'est pas vide. Dans certains systèmes internes, l'équipe technique de notre équipe est composée d'ingénieurs full-stack front-end et back-end, et nous répartissons le travail de développement des modules en fonction des besoins. Souvent, ils ne sont pas assez rigoureux pour vérifier les deux extrémités. Cela conduit également à des conflits quant à la finalité dans laquelle la spécification du service est orientée.

Notre choix final : l'équipe adopte une couche de service back-end. Mais en même temps, nous apporterons quelques améliorations, comme le déplacement de la vérification et d'autres fonctions au niveau de l'interface.

5.5 Qui veillera à ce que les spécifications du service soient rédigées correctement et que la technologie PK du produit

L'état idéal dans la phase initiale doit être vérifié par le produit côté demande, sur la base du principe selon lequel celui qui en a besoin le confirme. Cependant, en raison des différences dans 4.4, notre implémentation réelle est revue par le responsable technique.

6. Améliorations futures et résumé de l'application DDD

Application DDD ​​, l'équipe l'a actuellement implémentée du point de vue de l'architecture et des spécifications. Mais certains détails, tels que la conception des classes agrégées, des entités et des objets de valeur, ne sont pas particulièrement détaillés. Nous continuerons à faire progresser ces améliorations fines à l’avenir. Parallèlement, certains anciens projets en activité seront transformés et reconstruits selon les idées de DDD.

Certaines personnes pensent que l'application de DDD réduira l'efficacité du développement. C'est également une préoccupation de nombreuses équipes. C'est ainsi que nous envisageons ce problème. Le scénario d'application de DDD est de résoudre des problèmes commerciaux complexes, ce qui augmentera en effet la quantité de code. Mais cela ne signifie pas réduire l’efficacité du développement. Une structure architecturale claire, des services de domaine regroupés et des normes standardisées apporteront des avantages bien supérieurs à l'investissement dans les mises à niveau ultérieures de la demande, la maintenance du code et le contrôle de la complexité. De plus, selon les données fournies par l'industrie du logiciel, 80 % du temps est consacré à l'analyse de la demande et à la conception, tandis que le temps de développement ne représente que 20 %. C’est pourquoi cette partie de la perte n’est pas au centre de l’attention.

Enfin, décrivez votre expérience d'utilisation de DDD. Il existe de nombreux types de métamodèles DDD, et chacun peut les apprendre et les adopter de manière ciblée en fonction des problèmes rencontrés par l'entreprise. Dans l'environnement commercial actuel, nos modèles de domaine ont plus ou moins des « spécialités ». S'ils sont conformes à 100 % à la spécification DDD, le coût peut être relativement élevé, le plus important est donc de comprendre l'idée de DDD et de prendre la décision finale. choix. Une solution adaptée à votre entreprise.

À propos de l'auteur

Li Xiaohua

• Département commercial du concessionnaire-Département technologique du concessionnaire.
• A rejoint Autohome en 2016 et travaille actuellement dans l'équipe d'architecture de données du concessionnaire, responsable du projet de robot téléphonique.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!