1. Origines

Les styles d'architecture d'application adoptés par différentes équipes pour implémenter DDD peuvent être différents, et il n'existe pas d'architecture d'ingénierie DDD unifiée et standard. Certaines équipes peuvent suivre l'architecture classique à quatre niveaux DDD ou l'architecture améliorée à quatre niveaux DDD, certaines équipes peuvent considérer de manière exhaustive divers styles architecturaux tels que l'architecture en couches, l'architecture soignée et l'architecture hexagonale, et certaines peuvent introduire CQRS dans la pratique pour résoudre le problème de la lecture La différence entre le modèle et le modèle d'écriture et ainsi de suite. Même s'il est impossible de formuler une architecture d'application d'ingénierie commune et standard, il est toujours utile de développer une architecture de référence qui suit l'idée de conception axée sur le domaine pour l'équipe. Pour les raisons suivantes:

Fournir une référence d'ingénierie de démarrage rapide pour la conception tactique de l'équipe pour pratiquer DDD
Se référer à un grand nombre de décisions de nommage et de structure du projet, refléter explicitement les concepts pertinents de DDD et aider l'équipe à parvenir à un consensus sur la mise en œuvre tactique de DDD

Dans le même temps, l'architecture de référence permet de précipiter certaines des réflexions et des meilleures pratiques de l'équipe sur la conception pilotée par le domaine

2 Considérations pour les architectures de référence

Bien qu'il soit impossible de formuler une architecture de référence DDD complètement générale, il est faisable et pratique de formuler une architecture de référence dans un contexte spécifique. Le choix du contexte doit être aussi proche que possible du scénario réel de la pratique de l'ingénierie et tenir compte de facteurs multidimensionnels.

L'architecture d'ingénierie de référence décrite dans cet article respecte les principes suivants :

Suivant l'idée essentielle de la conception axée sur le domaine,
Tenir pleinement compte des caractéristiques de la construction du système d'entreprise
Minimisez les dépendances et gardez-les légères

On espère que l'architecture de référence technique couvrira les domaines suivants

Séparation des domaines métier et technique
- L'architecture de référence doit suivre les caractéristiques de la technologie et de l'isolation métier, et vous pouvez vous référer à une variété de tendances d'architecture. La séparation des préoccupations commerciales et techniques n'est pas une caractéristique unique de DDD.Ce principe important est suivi dans l'architecture hexagonale propre et les architectures en oignon.
Plusieurs scénarios de contexte délimité
- Lorsque la plupart des équipes divisent les microservices en fonction de DDD, en particulier au stade initial de la construction du système, la granularité du contexte délimité au sein d'une seule application de microservice doit être pesée. En raison des facteurs de structure organisationnelle de l'équipe et des problèmes de coût des microservices, une seule application s'adapte généralement à plusieurs contextes délimités (idéalement 1:1). Ces contextes délimités sont susceptibles d'être migrés vers des applications autonomes avec des itérations incrémentielles ultérieures. Par conséquent, les scénarios d'application multi-contexte à considérer dans l'architecture de référence.
Composants clairs, limites de responsabilité et dépendances

Prend en charge les scénarios de rapport de terrain
- Les scénarios de génération de rapports sont relativement courants dans les systèmes d'entreprise et DDD ne reflète pas la méthode de traitement de ce scénario. En tant qu'architecture de référence d'ingénierie, on espère toujours qu'elle pourra être déclenchée à partir de l'entreprise réelle pour refléter la prise en charge de l'affichage pour le modèle d'écriture et le modèle de rapport

Minimiser les dépendances externes
- En tant qu'architecture de référence, il est nécessaire d'éliminer les dépendances inutiles et de garder l'architecture d'ingénierie légère

3 Anatomie d'une architecture de référence

3.1 Structure multi-contexte de l'application

Sur la base des principes ci-dessus, le projet de référence considère le scénario de plusieurs contextes dans une seule application, afin de faire un compromis entre la modularité, la granularité du service et le coût. Le diagramme schématique de la prise en charge de plusieurs contextes par l'architecture d'application est présenté ci-dessous. Une fois que le domaine de la solution a identifié et divisé les contextes délimités, en fonction de leur cohésion et de leur pertinence métier, plusieurs contextes sont désormais inclus dans une seule application d'ingénierie. Il peut y avoir des interactions entre plusieurs contextes délimités dans une seule application, et la forme d'interaction peut être basée sur des appels événementiels ou en cours de processus. Le couplage entre les contextes est plus faible dans l'approche événementielle, mais nécessite généralement l'introduction d'un support de bus d'événements, et l'introduction de composants supplémentaires conduira inévitablement à une augmentation de la complexité. Les appels en cours auront un couplage plus élevé, mais la complexité sera moindre du point de vue de la mise en œuvre. Quelle manière de choisir spécifiquement, les développeurs peuvent faire des compromis en fonction de la situation réelle.

Il convient de noter à nouveau que cette décision d'architecture d'application est un compromis multifactoriel, qui peut ne pas être cohérent avec la pratique idéalisée du sous-domaine 1: 1 et du contexte délimité tel que nous le connaissons. Cependant, la considération globale du contexte d'une décision architecturale spécifique a toujours une valeur d'application pratique.

À partir du diagramme schématique logique ci-dessus, allons un peu plus loin et analysons la forme de présentation de l'architecture d'application détaillée à partir de la dimension en couches, comme illustré dans la figure suivante :

3.2 Préoccupations hiérarchiques

client

Le client est dans un processus différent de l'application et est le consommateur des fonctionnalités de l'application. Dans les projets réels, il peut s'agir de l'APP, du PC, de l'applet, du compte officiel ou de l'appelant professionnel tiers.

couche d'accès

La couche d'accès est la couche intermédiaire entre le système externe et les capacités métier internes de l'application. La couche d'accès est la façade externe de la couche application et l'entrée de l'application actuelle pour exposer les capacités métier au monde extérieur. La composition de cette couche peut être la déclaration d'interface HTTP fournie en externe, la planification de tâches de synchronisation distribuée, l'écouteur de messages, le service RPC, etc. Ses responsabilités importantes comprennent la vérification des paramètres de base, l'adaptation des paramètres d'entrée et le routage des services (transfert vers le service d'application à la première couche) et l'adaptation des données de réponse pour les demandes provenant de systèmes externes.

Couche métier :

Cette couche est la couche où réside la logique métier de l'application. L'ensemble du style architectural adopte un style unique modulaire, et différents contextes délimités dans cette couche sont incorporés dans différents modules. Une architecture en couches est adoptée dans chaque contexte délimité, qui est indépendamment divisé en couche application, couche domaine et couche passerelle.

Couche d'application:

Coordonnez les objets de domaine, les services de domaine ou les services dépendants externes pour compléter les cas d'utilisation métier. Cette couche coordonne uniquement les capacités et ne traite aucune logique de domaine.

couche de domaine :

La couche de domaine est au cœur de l'ensemble des couches et n'a rien à voir avec la mise en œuvre technique. Elle est principalement responsable des modèles de domaine, des événements de domaine, des définitions de service de domaine et de l'abstraction d'interface des services externes liés à l'entreprise et des interfaces d'entrepôt.

La différence essentielle entre la couche de domaine et les services d'application est que la couche d'application ne contient pas de logique de domaine et que toute la logique de domaine est abaissée à la couche de domaine pour la mise en œuvre.

Couche passerelle :

Le positionnement de la couche passerelle est la passerelle de sortie de l'application, une couche d'adaptation pour l'interaction entre l'application et l'infrastructure externe, et gère toutes les implémentations techniques connexes.

Il existe de nombreuses façons de nommer ce composant. Par exemple, certaines équipes l'ont nommé "rpc", et d'autres l'ont nommé "infrastructure". Différentes dénominations reflètent le choix de l'équipe quant à la métaphore qui la sous-tend. Dans l'architecture de référence de cet article, le nom gateway-Gateway a été choisi. La raison de cette décision est : le contexte délimité lui-même est très cohérent et son interaction avec l'extérieur nécessite une sortie unifiée. La signification de la passerelle exprimée par Gateway exprime correctement cette Le concept d'exportation unifiée. Si la couche Facade est la passerelle vers le nord de l'application, la passerelle exprime à ce moment la passerelle vers le sud du contexte délimité.

3.3 Composants et dépendances

À partir de la superposition de macros, approfondissons et examinons la division des composants de chaque couche. Comme indiqué ci-dessous:

Composant de démarrage :

L'entrée de démarrage de l'ensemble de l'application, le chargement des informations de configuration de l'application, etc.

Composants communs

Fournit l'abstraction des éléments de modèle de domaine qui sont réutilisés entre différents contextes délimités, tels que l'abstraction générale de Command, Query, Event, Entity, ValueObject, etc. Bien sûr, l'abstraction générale du modèle de domaine n'a pas besoin d'être réutilisée dans le composant commun. Elle peut également être utilisée comme un contexte délimité indépendant et partagé avec d'autres contextes en partageant le noyau, ou elle peut également être implémentée comme un contexte indépendant. composant de package jar.

Composants API

Le composant de déclaration d'interface du service de type RPC, prenant comme exemple le JSF utilisé à l'intérieur de l'entreprise, ce composant est le composant qui applique l'API JSF exposée au système externe. Ce composant peut être un projet indépendant, bien sûr, certaines équipes le mettront dans le projet d'application en tant que module.

Composant de façade unifié : Façade

L'entrée du client externe au système d'application est également la façade unifiée du service d'application interne, similaire à l'adaptateur dans le style d'architecture hexagonale. Basée sur différents scénarios, l'architecture de référence est divisée en plusieurs sous-packages, tels que fournisseur (service RPC), tâche (tâche planifiée), écouteur (surveillance MQ), repos (interface http), etc. Une fois la demande externe entrée dans le système, le composant Facade effectue des opérations telles que la vérification de base des paramètres d'entrée, la conversion des paramètres d'entrée, le routage des services et la conversion des paramètres de sortie. Dans le même temps, il peut également entreprendre des fonctionnalités connexes telles que le traitement de l'état de connexion, l'authentification et les journaux.

Composant de service d'application : service d'application

Les services applicatifs représentent des cas d'utilisation et des comportements système. Ils complètent le traitement de la logique applicative des cas d'utilisation en déléguant à la couche domaine et à la couche infrastructure (le composant Gateway dans l'architecture de référence). On peut comprendre que les services applicatifs sont des clients de la couche domaine. . Responsabilités typiques de ce composant :

Charger des objets de domaine à partir de la couche de stockage, déléguer des objets de domaine pour exécuter la logique de domaine et enregistrer des objets de domaine
Notification des événements importants à l'extérieur
Conversion et adaptation des paramètres d'entrée et de sortie
transaction en cours
Appels de service pour une logique externe hors domaine

API externe

La logique des services applicatifs doit non seulement coordonner la couche de domaine, mais aussi parfois s'appuyer sur des services tiers externes. Le composant API externe se charge de la déclaration d'interface et de la définition de ces services externes, sans implémentation spécifique.

Les composants de service d'application ne dépendent pas directement de l'implémentation de ces services externes, mais de leurs abstractions d'interface. En même temps, la définition du modèle ici est basée sur la sémantique du contexte borné, qui est une adaptation au modèle externe.

Ce composant ne dépend pas d'autres composants et ne dépend que des composants de service d'application et des composants de passerelle. Le composant de passerelle s'appuie sur la déclaration d'interface du composant d'API externe et fournit l'implémentation de la technologie sous-jacente, et le composant de service d'application s'appuie sur son interface et injecte l'implémentation spécifique via la méthode IOC pour terminer l'appel de service.

Notez que les services dont dépend ce composant n'impliquent pas de concepts de domaine, mais sont uniquement utilisés pour prendre en charge l'orchestration des services d'application. Si la logique de domaine est impliquée, les définitions d'interface qui dépendent des services externes doivent être abaissées à la couche Domaine.

Mettre en doute

Le composant Query résout les scénarios de requête de rapport liés au domaine et existe en tant que composant équivalent au service d'application dans le contexte délimité. Les deux composants sont respectivement responsables de la requête métier et de la logique de commande.

Bien que le composant Query ait été introduit pour prendre en charge les scénarios de rapport, le modèle CQRS n'a pas été entièrement introduit. Dans de nombreux documents, la probabilité que CQRS et DDD soient mentionnés en même temps est relativement élevée, car sous DDD, nous avons résolu le modèle d'écriture complexe orienté domaine, mais dans le scénario de rapport, ce modèle de domaine riche n'est peut-être pas le meilleur choix. Si le côté lecture et le côté écriture sont basés sur un modèle de domaine unifié, cela conduira généralement à une conception de compromis du modèle de domaine. Afin de répondre aux exigences du côté requête, le modèle de domaine doit introduire des attributs supplémentaires indépendants du domaine, provoquant ainsi une pollution du modèle de domaine.

Domaine

Le composant de domaine est le cœur de la logique de domaine et est responsable de la réalisation de la logique de domaine de l'ensemble du système. Il définit l'abstraction du modèle de domaine, des services de domaine, des événements de domaine et de la couche de stockage. Ce composant ne dépend pas d'autres composants (à l'exception du composant d'abstraction du modèle de domaine commun Common.

L'architecture de référence incarnée dans la figure ci-dessus utilise les éléments de modélisation classiques de la conception tactique de DDD, tels que l'agrégation, l'entité, l'objet de valeur, le stockage, l'usine et l'événement de domaine. Dans le processus de mise en œuvre proprement dit, l'abstraction de ces éléments de conception présente certains défis. Le processus de conception doit passer par une analyse continue, des compromis et une reconstruction pour compléter la modélisation, là où se trouve la conception de base.

passerelle

La couche passerelle (dans certaines architectures, elle peut devenir la couche infrastructure Infrastructure) est responsable de la réalisation de l'ensemble de la corrélation technique, et est la passerelle de sortie des applications internes.

La dépendance technique est la caractéristique fondamentale qui distingue les composants de la passerelle des autres composants. Tous les détails de la mise en œuvre technique doivent être traités dans ce composant, tels que l'interaction avec les services externes, le middleware, la base de données, etc. En même temps, il coopère avec l'abstraction d'interface des composants de domaine et des composants d'API externes, et entreprend conjointement la fonction de couche anti-corrosion entre le système et les dépendances externes (y compris les services externes et le middleware dépendant de l'application, la base de données et d'autres infrastructures), et est responsable de la transformation des modèles internes en modèles externes, de la conversion de modèle externe en modèle interne et des interactions spécifiques. Sur la base des caractéristiques du composant de passerelle, il convient également très bien à la mise en cache des données de service externe unifiée et au traitement des fusibles de rétrogradation au niveau de cette couche.

La couche passerelle dépend des composants Domaine, Service d'application, API externe et Requête, et est responsable de la mise en œuvre des interfaces définies par les quatre composants ci-dessus. Dans le composant Gateway, l'implémentation est isolée via des sous-packages :

query : interroge l'implémentation du composant de service
external : les composants API externes reposent sur l'implémentation d'interface de services externes
repository : l'implémentation de l'interface du repository

4 Épilogue

Le modèle d'architecture d'application est l'une des dimensions importantes de l'architecture. La structure n'est pas simplement une structure et un nommage de packages simples, mais une abstraction de haut niveau qui transmet beaucoup de pratique et de connaissances derrière elle. Il est très important de développer une architecture de référence d'ingénierie appropriée pour l'équipe et d'obtenir un consensus parmi les membres de l'équipe. La conception pilotée par domaine n'a pas d'architecture unifiée à usage général, et il n'est pas pratique d'essayer de définir une architecture standard. L'architecture d'ingénierie décrite dans cet article n'est qu'une référence. En pratique, elle devrait être différente en fonction de la situation spécifique de l'équipe, mais en principe, elle devrait suivre le concept de base consistant à séparer le domaine métier du domaine technique.

Faites attention au compte public WeChat : System Engineering Laboratory, obtenez plus d'informations

Architecture d'ingénierie de référence DDD