[Aperçu de la conférence Yuan Chuang] 1024 Journée des programmeurs (deux jours avant), rendez-vous au bureau Open Source Chine, parlons d'IA ! >>>

1. Introduction

1.1 Classement architectural

Dans le domaine de la conception de logiciels, l'architecture d'entreprise est généralement divisée en cinq catégories suivantes :

Comment comprendre les bases de la classification architecturale et leurs relations les unes avec les autres ? Les affaires sont la base de la survie d'une entreprise, donc l'architecture commerciale est le fondement et l'âme, et tout le reste est le support de l'architecture commerciale ; l'architecture de produit et l'architecture de données correspondantes sont formées sur la base de l'architecture commerciale ; et enfin mis en œuvre à travers l’architecture technique.

L'architecture d'application est utilisée pour subdiviser l'architecture de produit et former des produits grâce à l'intégration d'applications. Cependant, l'essence de la différence entre l'architecture d'application et l'architecture de produit ne doit pas résider uniquement dans la granularité. Plus important encore, le produit entreprend directement l'activité et est divisé en fonction du domaine du problème commercial, et l'application doit prendre en compte l'accumulation et la réutilisation. de capacités générales pour fournir un support unifié pour plusieurs produits.

Architecture métier : au début des exigences métier, les exigences floues sont décrites en domaines problématiques clairs, comprenant principalement la planification métier, les modules métier et les processus métier.
Architecture produit : Née de l'architecture métier (principalement processus métiers et modules métiers), elle se concentre sur l'énumération et la classification des fonctions.
Architecture des données : du point de vue de la définition du problème, la logique (processus) + les données sont les deux noyaux. Alors que l'architecture métier analyse les processus, un autre élément essentiel consiste à définir l'architecture des données et à combiner les processus et les données pour former des produits. En pratique, le travail d’architecture de données est souvent placé au sein de l’architecture produit ou de l’architecture applicative. D’un point de vue global, il s’agit d’un malentendu. Les données sont un atout précieux de l’entreprise, et la qualité de son architecture affecte directement la compétitivité de l’entreprise. entreprise. Elle doit être considérée et considérée de manière holistique. L'architecture des données doit résoudre deux questions clés : 1. Quelles données sont nécessaires 2. Comment stocker les données.
Architecture d'application : l'architecture d'application est utilisée pour subdiviser l'architecture du produit, effectuer un démontage plus fin des problèmes et une division des responsabilités en fonction de l'architecture du produit, et extraire des modules réutilisables pour former des fonctionnalités de base. L’implémentation la plus proche de l’architecture d’application.
Architecture technique : les quatre architectures ci-dessus partent du point de vue de la définition du problème, et l'architecture technique part du point de vue de la résolution du problème, en se concentrant sur la sélection de la technologie, le cadre de développement, le langage de développement, etc.

1.2 SOA

Depuis fin 2019, mon travail s'est concentré sur la construction de produits milieu de gamme dans le domaine de la chaîne d'approvisionnement. Un mot clé inévitable dans le processus de construction est la servitisation. Différentes personnes auront des points de vue différents à ce sujet. Personnellement, j'ai des points de vue différents sur la servitisation. La compréhension est plus encline à la SOA, parlons donc de la compréhension de la SOA à travers cet article.

En tant que style architectural, SOA est davantage un système idéologique d'architecture d'entreprise du point de vue de la classification de l'architecture. Il peut être utilisé comme méthodologie pour nous guider de la définition du modèle d'entreprise à la mise en œuvre de l'architecture d'entreprise globale. SOA met l'accent sur notre réflexion et notre conception sur la nature de l'entreprise, et trace, résume, résume et déduit en permanence la nature de l'entreprise par le biais de la co-création (méthode plutôt que forme) pour améliorer la flexibilité de l'entreprise, accélérer l'innovation commerciale et améliorer l'activité. Efficacité : l'architecture d'entreprise ne doit pas être ignorée et traitée comme un terme d'architecture d'application ou d'architecture technique. Souvent, lorsqu'on parle de servitisation, de nombreuses pratiques utiliseront des cadres techniques (plates-formes) pour remplacer de manière équivalente le concept de servitisation, et poursuivront la mise en œuvre de cadres techniques chauds (tels que sans serveur et sans code) dans les systèmes existants en tant que partie intégrante du système. thème principal de la construction orientée vers les services, une telle construction aboutit souvent à de mauvais résultats. La raison en est que l'utilisation de cadres techniques n'est qu'une technique et un outil, alors que l'essence de l'orientation service (SOA) est le Tao et la méthode.

L'architecture logicielle n'a pas encore connu de percées révolutionnaires après la proposition de la SOA. De nombreuses idées architecturales, telles que l'architecture en couches EA, l'architecture des microservices, l'architecture DDD, etc., sont pour la plupart évoluées et itérées sous différents angles en fonction du style architectural SOA. L'article est Le processus d'élaboration de SOA aura dans une certaine mesure des « ombres » d'autres idées architecturales.

2 Examinez la SOA sous trois angles : quoi, pourquoi et comment

2.1 Quoi

2.1.1 Terminologie

La définition de tout concept a sa terminologie correspondante.

Comportement commercial : une abstraction du comportement atomique avec certaines sémantiques commerciales.
Processus métier : une combinaison organique d'une série de comportements commerciaux qui atteignent une valeur commerciale spécifique (répondre aux besoins des clients).
Services métiers : comportements métiers ou processus métiers qui apportent de la valeur ajoutée (à noter que les services métiers peuvent être soit des processus métiers, soit des comportements métiers, voire une combinaison des deux). Ayez des définitions claires des fonctions commerciales et des mesures de valeur (SLA).
Composant d'application : ensemble de fonctions d'application structurées et packagées selon certaines corrélations (pour faciliter la compréhension, simplifiées et équivalentes aux services métier sans prendre en compte la superposition). Améliorer la cohérence, la flexibilité et la réutilisation des applications.
Application : ensemble organique de composants d'application utilisés pour fournir des fonctions commerciales (simples ou multiples) et fournir une prise en charge de valeur incrémentielle pour l'ensemble du système ou de la plate-forme. La planification de la demande, la planification commerciale, la planification des stocks, la planification de la distribution et du réapprovisionnement et la planification des approvisionnements de Jinghuizhong (il existe également certains concepts hiérarchiques entre les applications, qui sont proches de la compréhension de l'essence de l'entreprise).
Système : une combinaison organique d'une série d'applications et de services (certains services peuvent fournir indépendamment un support de valeur incrémentielle pour le système, ce qui se reflète dans de nombreuses idées d'architecture de microservices), avec des fonctions commerciales complètes de bout en bout, et fournit systématiquement aux utilisateurs valeur incrémentale. Le produit Jinghui (produit de planification de la chaîne d'approvisionnement) que j'ai construit est lui-même au niveau du système.
Plateforme : combinaison organique d'un ou plusieurs systèmes, avec un ensemble complet de fonctions commerciales de bout en bout pour l'ensemble du secteur d'activité ou de l'écosystème commercial. L’objectif est d’apporter une valeur métier globale aux métiers ou aux écosystèmes métiers.
Architecture : représente les éléments de base d'un système. Cela se reflète dans l'ensemble des éléments qui constituent le système, la relation entre les éléments, l'interaction avec l'environnement extérieur et les principes qui guident l'évolution itérative du système.
Style architectural : un ensemble de définitions architecturales partageant des caractéristiques et des principes fondamentaux communs.

2.1.2 Définition

SOA est un style architectural qui s'engage à utiliser des services dotés de fonctions métier cohérentes comme unité de base pour la conception, la construction et l'orchestration de processus métier (ou de solutions) combinés.

2.1.3 Prestations

Les services constituent l'unité de base pour la conception, la création et l'orchestration de solutions commerciales dans une entité commerciale complète.

Les services peuvent être définis dans deux directions : un service est une unité atomique (li) qui fournit des fonctions commerciales et est gérée via un contrat de service (table).

Un contrat de service est un ensemble de tous les accords entre consommateurs de services et fournisseurs de services. Il se compose généralement des éléments suivants :
Interface de service : définition de l'interface, décrivant ce que fait le service, définitions des paramètres entrants et sortants, etc., généralement présentée sous la forme d'un document d'interface. Fonctionne autour d’une fonction commerciale principale et des opérations associées.

Stratégie de service : consensus implicite entre les parties du service, décrivant les scénarios d'adaptation, les contraintes, etc.
Niveau de service : le service lui-même est mesuré à travers divers aspects tels que la qualité du service, la disponibilité, les performances, etc. Il est fondamentalement équivalent au SLA et comprend deux aspects importants des indicateurs de service : les indicateurs commerciaux et les indicateurs techniques (indicateurs techniques - RT, débit, disponibilité, fiabilité, etc.; indicateurs commerciaux - la qualité ou le degré d'achèvement des fonctions commerciales réalisées, par exemple si les suggestions de réapprovisionnement répondent aux attentes de l'entreprise (chiffre d'affaires et KPI de rupture de stock).

Les attributs de gestion reflétés dans le contrat de service constituent la différence fondamentale entre les services et d'autres définitions courantes (modules, composants, etc.). Nous utilisons des contrats de service pour gérer le cycle de vie complet des services (conception, mise en œuvre, déploiement, mise à niveau).

Implémentation de services - la réalisation des fonctions métiers est une cartographie de l'essence même de la SOA.

Implémentation du service : il existe plusieurs méthodes d'implémentation [implémentation du codage | orchestration d'autres services | adaptation et encapsulation d'applications existantes | implémentation hybride]. La manière dont le service est mis en œuvre est transparente pour le consommateur du service, c'est-à-dire que le consommateur du service ne se soucie que du quoi du service plutôt que du comment. Les services peuvent être modifiés dans les directions horizontale et verticale tout en gardant l'interface inchangée (offrant horizontalement différentes implémentations selon différents scénarios dans différentes industries ; services évoluant verticalement en fonction du développement de l'industrie).

2.2 Pourquoi

Pourquoi choisir SOA ? Il existe de nombreuses opinions sur cette question

Des responsabilités claires (définition de l'interface)
Expansion flexible (séparation de l'interface et de l'implémentation)
Hautement réutilisable
Classement des interfaces
Très gérable

Aucun des points ci-dessus ne peut être nié car ils peuvent être dérivés de la définition du service. Les trois premiers visent tous à construire un service unique. Tant que vous maîtrisez suffisamment de moyens techniques, vous pouvez facilement créer un service (single service). Ce n'est pas le cœur de la compétitivité de la SOA. L'objectif de la SOA va bien au-delà de la conception et de la définition des détails techniques de l'interface : l'accent est mis sur le contenu métier et la connotation des services (plutôt que sur la manière de les concevoir et de les mettre en œuvre). En utilisant les techniques et outils résumés et affinés par SOA, n’oubliez pas le Tao et le Dharma. La façon de faire est très importante, elle vous guide pour bien faire quelque chose ; mais ce qui est plus important, elle vous guide pour faire la bonne chose.

Pour analyser en profondeur la valeur de la SOA, nous devons revenir à l'essence de la SOA - s'engager à créer des services axés sur les fonctions métier dans différents environnements commerciaux au sein de l'entreprise et, sur cette base, à assembler les services dans des processus métiers de plus grande valeur/de plus haut niveau ( Solution). Par conséquent, la valeur de la SOA peut être résumée en deux points clés :

Donnez aux entreprises les moyens de créer des collections de services ayant une valeur commerciale et une sémantique commerciale complète ;
Sur la base de la collecte de services, organiser et orchestrer les services pour créer des processus/solutions métier agiles et flexibles. [Les services agiles peuvent être rapidement ajustés et évoluer de manière indépendante ; les fonctions commerciales des services flexibles sont clairement définies (limites claires et forte cohésion) et peuvent être combinées de manière flexible]

2.2.1 Formes d'expression de la valeur SOA

Cohérence : la cohérence est la valeur fondamentale de la SOA, y compris la cohérence des données et la cohérence du comportement [les données fournissent des services d'accès aux données publiques cohérents et consensuels ; le comportement fournit une entrée unifiée vers le monde extérieur (processus métier, tâches externes, etc.)]
Découplage : Réduisez la dépendance et le couplage entre les fonctions et les données grâce à la séparation. En tant qu'unités fonctionnelles commerciales indépendantes, les services peuvent fonctionner ensemble dans le système d'application, et chacun a ses propres objectifs commerciaux et son propre cycle de vie, clairs et indépendants.
Modularité et agilité : fournit une base pour la modularisation de l'entreprise ; en même temps, sur la base d'une mise en œuvre modulaire, les modules peuvent être réutilisés et combinés de manière flexible dans plusieurs processus et scénarios commerciaux, soutenant ainsi une innovation commerciale rapide.
Haut degré de gérabilité : la définition des niveaux de service garantit que, tout en soutenant les objectifs commerciaux, les services peuvent être gérés au-delà de la cognition des fonctions métier (surveillables, optimisables et ajustables).

2.3 Comment

Par rapport au quoi et au pourquoi, la pratique de la SOA constitue un énorme problème. Cet article choisit de l'analyser du point de vue de la conception des services.

2.3.1 Faire le tri dans le contexte

Pour les systèmes d'entreprise, comprendre les entreprises que nous soutenons et leurs principales forces motrices est la condition préalable pour que nous puissions faire du bon travail en matière de servitisation ; s'il s'agit d'un système de plate-forme, nous devons comprendre la mission de la plate-forme donnée par la stratégie de l'entreprise et le objectif ultime, objectifs à moyen et long terme de la plateforme. En d’autres termes, la première étape consiste à clarifier le contexte complet de l’architecture de servitisation. Ces contenus doivent être mappés dans le modèle (modèles à chaque niveau, voir la conception en couches ci-dessous pour plus de détails). Comment trier le contexte, une bonne pratique consiste à définir l’ensemble du problème. Il existe un point de vue selon lequel poser de bonnes questions == la moitié du problème est résolue.

Le contexte de l'ensemble de l'architecture basée sur les services est décrit à travers les huit questions ci-dessus :

Question 1-6 : Décrire les exigences globales en matière d'architecture de l'entreprise/de la plateforme ;
Question 7 : Décrivez la conclusion de l'examen des exigences architecturales ;
Problème 8 : Les définitions de la collection de services sont introduites. La collecte de services est la principale réalisation de la construction SOA et doit être comprise dans la perspective d’une évolution itérative continue.

Nous reflétons la sémantique métier complète et la sémantique de la plateforme à travers des collections de services. Comment déterminer si une collection de services a une sémantique contextuelle complète doit être capable d'identifier les éléments suivants :

contexte complet
Portée des responsabilités en matière de collecte de services
Regroupement de services (reflétant la pertinence du service)
Types et rôles des services

Deux objectifs principaux de la conception de collections de services

Fournir un mécanisme pour identifier les limites de responsabilité d’un service spécifique et guider la mise en œuvre du service. (Il est important de clarifier les responsabilités et les limites du service, d'éviter la duplication de la construction et d'assurer la cohérence des comportements et des données)
Fournir un mécanisme pour aider à comprendre le contexte global du service pour une sélection et une réutilisation plus efficaces des services. (Classification des services, corrélation entre services)

Les services d'une collection de services peuvent être organisés en fonction de types de services et de rôles de service. Les types de services sont décrits en référence à l'architecture en couches orientée services. Les rôles de service comprennent les rôles de service de tâches, les rôles de service d'entité et les rôles de service de prise de décision.

2.3.2 Principes de conception des services

L'une des clés du succès de la SOA est de créer une collection de services avec une sémantique contextuelle complète (sémantique métier/plateforme) afin que différents processus métier et scénarios métier puissent être pris en charge en combinant des services d'orchestration. Les problèmes de conception de services dans une architecture orientée services doivent être pris en compte dans plusieurs, voire dans tous les processus.

Tout d'abord, la chose la plus simple à laquelle penser est le couplage lâche. Qu'il s'agisse de la pensée SOA ou d'autres idées (par exemple POO), le couplage lâche est l'un des principes de base ; en réduisant les dépendances entre les services, il améliore la réutilisabilité dans différents scénarios d'application et isole l’impact des changements. Couplage - Il existe des dépendances entre les services. Tout d’abord, examinons les deux points les plus importants en matière de service :

Fonctions commerciales fournies par le service
L'impact des services sur les données d'entreprise

À partir des deux points ci-dessus, nous pouvons facilement déduire deux types de couplage (dépendance) : les données et les fonctionnalités. Il y a ici une question très fondamentale sur la raison pour laquelle les dépendances sont générées. Du point de vue de la mise en œuvre technique, les dépendances peuvent être abandonnées pour mettre en œuvre un service vaste et complet. Les développeurs, en particulier ceux qui sont habitués à la pensée orientée objet, ont développé un instinct de couplage lâche/cohésion élevée et réfléchissent rarement aux raisons pour lesquelles ils le font - deux aspects (garantie de cohérence interne ; réutilisation des capacités externes). Une bonne conception de services ne se concentre pas uniquement sur la réutilisabilité, mais, plus important encore, assure la cohérence (comportement et données).

Encore une fois, comment décidez-vous quels services sont disponibles et lesquels ? Toujours à partir des données et des fonctions, nous utilisons la décomposition fonctionnelle et l'isolation des données pour déterminer quels services existent et lesquels. Les principes de base dérivés de cette extension sont les suivants :

éviter de manquer
éviter les doublons
maintenir la cohérence

Comment mettre en œuvre les principes ci-dessus ? Vous pouvez utiliser la définition et la transformation d'ensembles de problèmes :

2.3.3 Conception de la collection de services

Nous examinons la conception des collections de services sous trois aspects étroitement liés : la superposition, la classification et la segmentation granulaire.

Hiérarchisation des services

L'architecture de l'information est un aspect important qui sera négligé dans la conception d'une architecture en couches orientée services, reflétant les préoccupations des différents rôles dans l'entreprise.

La stratégie et la prise de décision définissent l'orientation stratégique et les objectifs commerciaux de l'entreprise, et guident l'orientation et les résultats du développement des systèmes/plateformes internes de l'entreprise.
Un modèle économique décrit en termes d’entité opérationnelle ce qui est précieux pour l’entreprise.
L'abstraction métier résume l'activité d'un ou de plusieurs secteurs d'activité d'une manière basée sur l'information. Partez de l’abstraction métier et entrez la définition du domaine problématique.
Le modèle sémantique public ajoute une sémantique orientée services basée sur l'abstraction métier. Le modèle sémantique public décrit les entités commerciales et les informations avec une sémantique cohérente partagée entre divers services métiers sur la plateforme, et nécessite un consensus au niveau de la couche plateforme.
Le modèle de domaine de sous-domaine est une abstraction des fonctions commerciales essentielles de chaque sous-domaine, y compris la définition du service et la définition des entités clés dans la mise en œuvre du service. D'un point de vue global, il s'agit d'un modèle privé de chaque sous-domaine de la plateforme, et n'est visible du monde extérieur que pour la sémantique du service.
Le modèle de mise en œuvre du développement est équivalent au modèle objet en POO et constitue la pierre angulaire du développement et de la mise en œuvre.

La relation entre le modèle économique et l’abstraction commerciale

1-Le modèle commercial décrit le processus métier perçu par les opérateurs commerciaux ; l'abstraction métier décrit non seulement le processus métier, mais, plus important encore, décrit de manière abstraite les fonctions métier sous-jacentes que le processus métier doit contenir.
2-Le modèle économique décrit toutes les choses importantes pour l'activité de l'entreprise ; le résumé commercial décrit le contenu le plus fondamental derrière les choses que l'entreprise souhaite.

Bien que le modèle économique soit la couche supérieure d'abstraction métier à partir d'une structure hiérarchique, ce qu'il décrit est l'échantillon ou l'instance correspondant à la définition de l'abstraction métier (conceptuellement, la portée de l'abstraction métier est plus large). L'abstraction commerciale est l'abstraction et la synthèse de modèles commerciaux. Elle doit être soigneusement analysée et résumée, et même définie de manière déductive pour définir le contenu et la structure fondamentaux cachés derrière le corps principal des opérations commerciales de l'entreprise.

La relation entre le modèle sémantique commun et le modèle de domaine de sous-domaine

Le modèle sémantique commun est utilisé pour décrire les informations partagées de l'interaction d'interface de service de couche plate-forme et est basé sur le modèle de vue standardisé des données communes de tous les services sous la sémantique commerciale complète de la plate-forme. En bref, le modèle sémantique public de la plateforme définit la sémantique de base des services métiers au niveau de la plateforme métier.Il s'agit d'un langage unifié pour l'interaction entre les services métiers de la plateforme, les processus métiers de la plateforme et les services métiers de la plateforme, en mettant l'accent sur l'unification et le partage. Le modèle de domaine de sous-domaine est un modèle privé de chaque domaine de la plateforme, qui est utilisé pour piloter la conception et la mise en œuvre des fonctions de service dans le sous-domaine. À moins qu'il n'y ait des changements essentiels dans l'activité au sein du domaine, le modèle de domaine de sous-domaine doit rester dynamiquement stable et isoler l'érosion des dépendances externes via la couche anti-corruption (le modèle de domaine est également au cœur de l'idée DDD).

La stratification des services constitue l'élément principal de la conception d'une architecture en couches orientée services. Un bon moyen de comprendre l'architecture en couches de services est d'apprendre le méta-modèle TOGAF.

Processus métier (de bout en bout) : opérations commerciales effectuées dans une séquence déterminée par certaines règles métier. Les fonctions métiers de haut niveau couvrent généralement plusieurs sous-domaines d’application/secteurs d’activité.
Services métiers (plateforme/système) : unités fonctionnelles métiers hautement modulaires. Il est composé de différents types de combinaisons de services de sous-domaines et peut être utilisé comme unité d'orchestration pour les processus métier.
Services de sous-domaines : les services fournis par les sous-domaines fonctionnels sont visibles par la plateforme et sont utilisés pour l'orchestration combinée des services métier de la plateforme. Ils peuvent également être utilisés comme unité de base pour l'orchestration des processus métier de niveau supérieur.
Services de base du sous-domaine : services de base utilisés pour prendre en charge divers services fonctionnels du sous-domaine. Ils sont visibles par le sous-domaine mais invisibles par la plateforme. Ils sont utilisés pour l'orchestration des services du sous-domaine.
Services de sous-domaines de base : ou appelés services de domaine commercial de base, fournissent des services commerciaux de base sur la plate-forme et fournissent des fonctions commerciales de base et des services de données (par exemple, services marchands, services de biens, services d'inventaire) pour chaque sous-domaine fonctionnel ou services commerciaux de plate-forme.
Services d'infrastructure : fournir des services d'infrastructure partagés par différents niveaux (par exemple, gestion des utilisateurs, gestion des droits)

La superposition de modèles est un complément important à la superposition de services. La stratification des services est claire et complète d'un point de vue structurel, mais elle n'est pas complète du point de vue global de la construction orientée services.Nous devons ajouter l'abstraction du modèle correspondant.

Modèle de base : le processus métier de bout en bout porte le modèle d'information de la valeur fondamentale de l'entreprise. Dans le domaine de la chaîne d'approvisionnement, il s'agit du modèle de document, tel qu'une commande client, un bon de commande et un ordre de plan de réapprovisionnement.
Modèle sémantique public : définit les processus métier au niveau de la plateforme et les données d'interaction avec les services métier. Au niveau de la plate-forme ou de l'entreprise, le modèle sémantique commun d'informations interactives dans le processus métier de bout en bout définit la définition complète de l'entité sémantique métier requise dans le processus métier (chaque entité sémantique métier a des limites et des responsabilités claires). Le modèle central est généralement un sous-ensemble du modèle sémantique commun. Le modèle sémantique public de la plate-forme comprend un sous-ensemble d'entités de service externes du sous-domaine inférieur. Selon la sémantique commerciale complète de la plate-forme de bout en bout, il peut être intégré de manière organique à partir du sous-ensemble d'entités principales partagé par chaque modèle de sous-domaine fonctionnel. de la plate-forme à la plate-forme, ou elle peut être formée par la plate-forme. Une nouvelle définition du modèle commercial (combiné de haut en bas et de bas en haut). Ce modèle nécessite une évolution itérative continue, et de nombreuses décisions architecturales et améliorations de la plateforme sont basées sur ce modèle.
Modèle de domaine de sous-domaine : le modèle de domaine de chaque sous-domaine fonctionnel de la plate-forme est utilisé pour piloter la conception et le développement du système d'application de chaque sous-domaine fonctionnel. (La description hiérarchique du même service doit maintenir une stabilité dynamique et isoler les services externes via la couche anti-corruption pour empêcher les services externes de polluer la sémantique métier de base dans le sous-domaine, tout en gardant les fonctions métier du domaine flexibles et contrôlables. Le modèle de domaine de sous-domaine utilise uniquement ses entités de service externes visibles au monde extérieur, d'autres sont invisibles au monde extérieur.)
Modèle de cartographie inter-domaines : utilisé pour chaque modèle de domaine de sous-domaine pour obtenir une dépendance anticorrosion vis-à-vis des modèles externes.
Modèle de service d'infrastructure : fournit un modèle d'informations d'infrastructure commun qui sort de la hiérarchie, tel qu'un modèle d'utilisateur et un modèle d'autorisation.

Classement des services

La classification des services (ou rôle du service) est un autre facteur important, indépendant de l'étendue des responsabilités et de la granularité du service ; elle est utilisée pour identifier le rôle que jouent les services dans l'orchestration de la composition/des processus.
Si la stratification des services est une segmentation verticale, la classification des services est une section transversale. En nous appuyant sur les concepts de POO et d'AOP, nous utilisons le principe architectural de séparation des préoccupations pour définir les classifications de services.

Nous définissons généralement trois grandes catégories de services avec une granularité plus grossière :

Service de tâches : le service de tâches implémente généralement une fonction métier complète, qui peut être soit une fonction métier de base, soit une fonction métier complexe. Ce type de service a une granularité grossière, allant des services de base de sous-domaines indépendants aux services métier de plate-forme pouvant avoir des rôles de service de tâches. Les services métiers assument généralement le rôle de services de tâches. Ils constituent eux-mêmes une combinaison (processus) plus large de services à petite granularité et peuvent être conçus pour prendre en charge un ou plusieurs processus en attente. Les services de tâches sont très ciblés et ont une faible réutilisabilité. Habituellement, un service avec des tâches est un service actif, qui génère de la valeur via des comportements actifs.
Services d'entité : services qui gèrent l'accès aux entités commerciales. Par exemple, les utilisateurs, les catégories, les produits et les paniers. Les services d'entité sont généralement indépendants de tout processus métier spécifique et peuvent être des composants de plusieurs processus métier différents. Les services d'entité prennent généralement en charge les services de tâches en fournissant les informations requises pour mettre en œuvre la tâche. Les services d'entité ont généralement un fort potentiel de réutilisation.
Services de règles/décision : services qui fournissent des décisions commerciales en exécutant des règles métier. Par exemple, prenons le service de révision automatique du plan de réapprovisionnement. Il est généralement utilisé pour évaluer des problèmes complexes ou pour prendre en charge des règles métier qui changent fréquemment. En termes de granularité, les services de règles/décisions sont généralement petits à moyens et sont utilisés pour assembler des services plus importants. Les services de règles/décisions peuvent être des services à différents niveaux (y compris les services métiers, les services de sous-domaines, les services de base de sous-domaines, etc.), mais ils sont plus couramment utilisés comme services de base pour prendre en charge ces services.

Nous fournissons des capacités commerciales flexibles en combinant différents types de rôles de service pour prendre en charge les activités au sein des processus commerciaux. Par conséquent, certains principes de base sont nécessaires pour nous aider à combiner raisonnablement les services (réduire les dépendances, limiter le couplage et obtenir une flexibilité maximale) - principes de base de la superposition et de la composition des services :

Les tâches des processus métier sont mises en œuvre via des services de tâches, et les règles de base du routage des processus métier sont fournies par les services de règles/décisions.
Les services métiers de niveau supérieur sont composés d'autres services plus petits.
Les services de tâches peuvent combiner des services de règles/décisions, des services d'entités et d'autres services de tâches
Les services d'entité ne permettent pas les appels mutuels
Les services dépendent d'un sens. Les services de couche supérieure peuvent s'appuyer sur des services de couche inférieure et des services du même niveau. Les services de couche inférieure ne peuvent pas s'appuyer sur des services de couche supérieure.

Créer des services (processus) nouveaux et différents grâce à une riche collection de processus, d'entités et de services de prise de décision ; combiner la flexibilité des règles/décisions avec la modularité et la réutilisabilité de la superposition de services pour créer une architecture pour la mise en œuvre de pratiques système/plateforme. Méthodologie .

Segmentation de granularité

Lorsque nous concevons des services, un grand doute se pose : quel type de granularité nos services doivent-ils être conçus ? Il n'existe pas de norme unifiée pour ce problème. Il peut être résolu en définissant une combinaison d'ensembles de problèmes et en combinant la superposition de services.

Qui sont les consommateurs de services (y compris les consommateurs potentiels), par exemple d'autres services, processus commerciaux, partenaires externes
Où le service est consommé et par quel chemin il est consommé (c'est-à-dire topologie du service)
Exigences de performance des services
Portée commerciale attendue et limites des services

Dans des environnements ou des systèmes complexes (plateformes), les services ont différents types et granularités. Une méthode courante consiste à se référer à la couche de services pour un mappage raisonnable :

Processus métier (de bout en bout) : couvre l'ensemble de l'entreprise ou plusieurs domaines métier de la plateforme, et est généralement construit à partir de services sous-jacents
Services commerciaux de plate-forme : services les plus grossiers, fournissant des fonctions commerciales combinées très abstraites aux plates-formes ou aux entreprises. Les fonctions et les données des services métier sont étroitement intégrées à la sémantique métier requise par les processus métier. Les services d'intégration de données fournissent les données intégrées nécessaires aux processus métier de bout en bout à ce niveau.
Services de sous-domaine : services de granularité moyenne qui fournissent des services liés à l'entreprise pour chaque sous-domaine d'entreprise. Ils sont utilisés par différents services d'entreprise au sein du sous-domaine, mais ne sont pas nécessairement exposés en dehors du sous-domaine.
Service de base du sous-domaine : le plus petit service granulaire, fournissant des services de bas niveau pour fournir un support fonctionnel de base pour les fonctions commerciales du sous-domaine.
Services de sous-domaines de base : services plus fins qui prennent en charge la mise en œuvre des fonctions métier des services de fonctions métier de couche supérieure.
Services d'infrastructure : services plus précis, indépendants de tout domaine d'activité. (Clairement distingué du business, par exemple authentification de sécurité, gestion des autorités, etc.)

3 Résumé

Le champ d'application de l'architecture est trop vaste et trop large. Cet article tente d'expliquer ma compréhension personnelle à partir d'un point. Il y a trop de problèmes connexes sur lesquels je souhaite développer, tels que la combinaison de SOA et de BPM, les détails rencontrés dans le processus de pratique, etc., mais ils ont été supprimés afin d'analyser SOA plus proprement. J'espère que vous, lecteurs, gagnerez quelque chose.

Auteur : JD Logistics Cui Liqun

Source : JD Cloud Developer Community Ziyuanqishuo Tech Veuillez indiquer la source lors de la réimpression

Cognition et méthodologie SOA | Équipe technologique de JD Logistics