Modifier

Partager via


Architecture monolithique propre Gridwich

Azure Event Grid
Azure Functions

Le code de ce projet est organisé comme une architecture monolithique propre, avec les composants conceptuels typiques suivants :

  • Adaptateurs d’API
  • Logique métier d’application découplée
  • Objets de domaine de base
  • Passerelles d’infrastructure
  • Inversion de contrôle (IoC)

Diagram showing typical conceptual components of a clean monolith architecture.

Sans état, la solution ne contient pas de passerelle vers des couches de persistance. La solution n’a pas d’interface utilisateur et n’a donc aucun contrôleur ni présentateur.

La composition du composant logiciel utilise la classe GridwichConfigureServices pour définir quelles classes concrètes sont disponibles dans le conteneur IoC pour l’application Azure Functions.

Architecture

Diagram showing components of the Gridwich monolith architecture.

La solution Gridwich possède une bibliothèque Core.EventGrid qui contient :

  • Les objets de transfert de données (DTO) de requête et réponse de domaine.
  • Les interfaces de la logique métier ou les objets de service de l’application.
  • Les classes de base qui permettent d’atteindre une logique ou des activités courantes pilotées par le domaine.
  • Les définitions de la journalisation, de l’observation et des exceptions à utiliser dans toute l’application.

Pour encapsuler Azure Event Grid en tant que service Broker de requête et réponse, la bibliothèque possède :

  • Un répartiteur d’événements qui utilise l’IoC pour identifier et distribuer des événements aux écouteurs.
  • Un éditeur d’événements pour placer les réponses dans la rubrique Event Grid correcte.

L’adaptateur de requête Event Grid est un point de terminaison HTTP sous la forme d’un point de terminaison HTTP Azure Function. Un adaptateur de conversion des requêtes web en tableaux Event Grid réside également dans la même EventGridFunction.

La passerelle de réponse Event Grid se compose des éléments suivants :

  • Le EventGridHandlerBase, qui convertit un DTO de réponse en objet EventGridEvent.
  • Le EventGridDispatcher, qui place l’événement Event Grid sur la réponse appropriée de l’URI du point de terminaison de rubrique Event Grid à l’aide de la clé de rubrique.

La solution dissocie les participants de saga dans les bibliothèques suivantes, qui ont des responsabilités sur la logique métier de l’application spécifique à un domaine. Les bibliothèques contiennent les passerelles d’infrastructure requises et leurs kits de développement logiciel (SDK), qui effectuent les actions requises par la logique métier.

Pour la réutilisation et la centralisation du code, Gridwich consolide la logique métier ou les passerelles d’infrastructure que plusieurs participants utilisent dans les bibliothèques partagées suivantes :

Alternative aux microservices

Rien dans l’espace ou l’architecture du problème Gridwich pousse explicitement à choisir une application monolithique ou plusieurs microservices pour y remédier.

Vous pouvez facilement refactoriser l’application en microservices, chaque application de fonction hébergeant un seul participant saga. Chaque application de fonction lie les bibliothèques principales et EventGrid principales. Les applications ont chacune une liaison ou utilisent une bibliothèque commune pour les passerelles d’infrastructure.

Diagram showing an alternative Gridwich microservices architecture.

Une telle approche de microservices offre la possibilité d’une mise à l’échelle différente pour chaque type de requête. S’il y avait des milliers de requêtes d’un type particulier chaque seconde, mais seulement des centaines de requêtes d’un autre type chaque jour, la solution globale bénéficierait de fonctions plus petites, faciles à quantifier et rapides à exécuter pour les requêtes volumineuses.

L’inconvénient des microservices est que tout modèle partagé nécessite un déploiement synchronisé des microservices ou demande une vidange du pool et un basculement en cas de modification du schéma de données. Cette exigence compliquerait le développement futur, le déploiement continu et les opérations. Étant donné que le problème de l’entreprise n’a pas démontré un besoin pour les microservices, l’architecture Gridwich utilise une approche monolithique propre.

Étapes suivantes