Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modèle de couche anticorruption

Intention

Le modèle de couche anticorruption (ACL) agit comme une couche de médiation qui traduit la sémantique du modèle de domaine d'un système à un autre. Il traduit le modèle du contexte délimité en amont (monolithe) en un modèle adapté au contexte délimité en aval (microservice) avant d'utiliser le contrat de communication établi par l'équipe en amont. Ce modèle peut s'appliquer lorsque le contexte délimité en aval contient un sous-domaine principal ou lorsque le modèle en amont est un système existant non modifiable. Elle réduit également les risques liés à la transformation et à l'interruption des activités en empêchant toute modification des appelants lorsque leurs appels doivent être redirigés de manière transparente vers le système cible.

Motivation

Au cours du processus de migration, lorsqu'une application monolithique est migrée vers des microservices, des modifications peuvent survenir dans la sémantique du modèle de domaine du service nouvellement migré. Lorsque les fonctionnalités du monolithe sont requises pour appeler ces microservices, les appels doivent être routés vers le service migré sans nécessiter de modification des services appelants. Le modèle ACL permet au monolithe d'appeler les microservices de manière transparente en agissant comme un adaptateur ou une couche de façade qui traduit les appels selon la nouvelle sémantique.

Applicabilité

Envisagez d'utiliser ce modèle lorsque :

Enjeux et considérations

Mise en œuvre

Vous pouvez implémenter l'ACL dans votre application monolithique en tant que classe spécifique au service en cours de migration ou en tant que service indépendant. L'ACL doit être mis hors service une fois que tous les services dépendants ont été migrés vers l'architecture de microservices.

Architecture de haut niveau

Dans l'exemple d'architecture suivant, une application monolithique possède trois services : le service utilisateur, le service du panier et le service des comptes. Le service de panier dépend du service utilisateur et l'application utilise une base de données relationnelle monolithique.

Dans l'architecture suivante, le service utilisateur a été migré vers un nouveau microservice. Le service de panier appelle le service utilisateur, mais l'implémentation n'est plus disponible dans le monolithe.  Il est également probable que l'interface du service nouvellement migré ne corresponde pas à son interface précédente, lorsqu'il se trouvait dans l'application monolithique.

Si le service de panier doit appeler directement le service utilisateur récemment migré, cela nécessitera des modifications du service de panier et des tests approfondis de l'application monolithique. Cela peut accroître le risque de transformation et d'interruption des activités. L'objectif doit être de minimiser les modifications apportées aux fonctionnalités existantes de l'application monolithique.

Dans ce cas, nous vous recommandons d'introduire une ACL entre l'ancien service utilisateur et le service utilisateur récemment migré. L'ACL fonctionne comme un adaptateur ou une façade qui convertit les appels vers la nouvelle interface. L'ACL peut être implémentée dans l'application monolithique en tant que classe (par exemple,UserServiceFacadeouUserServiceAdapter) qui est spécifique au service qui a été migré. La couche anticorruption doit être mise hors service une fois que tous les services dépendants ont été migrés vers l'architecture de microservices.

Mise en œuvre en utilisantAWSservices

Le schéma suivant montre comment vous pouvez implémenter cet exemple d'ACL en utilisantAWSservices.

Le microservice utilisateur est migré hors de l'application monolithique ASP.NET et déployé en tant queAWS Lambdafonctionne sur AWS. Les appels à la fonction Lambda sont acheminés viaPasserelle d'API Amazon. L'ACL est déployée dans le monolithe pour traduire l'appel afin de l'adapter à la sémantique du microservice utilisateur.

QuandProgram.csappelle le service utilisateur (UserInMonolith.cs) à l'intérieur du monolithe, l'appel est acheminé vers l'ACL (UserServiceACL.cs). L'ACL traduit l'appel vers la nouvelle sémantique et la nouvelle interface, et appelle le microservice via le point de terminaison API Gateway. L'appelant (Program.cs) n'est pas au courant de la traduction et du routage qui ont lieu dans le service utilisateur et l'ACL. Comme l'appelant n'est pas au courant des modifications apportées au code, il y a moins de perturbations opérationnelles et moins de risques de transformation.

Exemple de code

L'extrait de code suivant fournit les modifications apportées au service d'origine et l'implémentation deUserServiceACL.cs. Lorsqu'une demande est reçue, le service utilisateur d'origine appelle l'ACL. L'ACL convertit l'objet source pour qu'il corresponde à l'interface du service récemment migré, appelle le service et renvoie la réponse à l'appelant.

public class UserInMonolith: IUserInMonolith
{
    private readonly IACL _userServiceACL;
    public UserInMonolith(IACL userServiceACL) => (_userServiceACL) = (userServiceACL);
    public async Task<HttpStatusCode> UpdateAddress(UserDetails userDetails)
    {
        //Wrap the original object in the derived class 
        var destUserDetails = new UserDetailsWrapped("user", userDetails);
        //Logic for updating address has been moved to a microservice
        return await _userServiceACL.CallMicroservice(destUserDetails);
    }
}

public class UserServiceACL: IACL
{
    static HttpClient _client = new HttpClient();
    private static string _apiGatewayDev = string.Empty;

    public UserServiceACL()
    {
        IConfiguration config = new ConfigurationBuilder().AddJsonFile(AppContext.BaseDirectory + "../../../config.json").Build();
        _apiGatewayDev = config["APIGatewayURL:Dev"];
        _client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    }
    public async Task<HttpStatusCode> CallMicroservice(ISourceObject details)
    {
        _apiGatewayDev +=  "/" + details.ServiceName;
        Console.WriteLine(_apiGatewayDev);

        var userDetails = details as UserDetails;
        var userMicroserviceModel = new UserMicroserviceModel();
        userMicroserviceModel.UserId = userDetails.UserId;
        userMicroserviceModel.Address = userDetails.AddressLine1 + ", " + userDetails.AddressLine2;
        userMicroserviceModel.City = userDetails.City;
        userMicroserviceModel.State = userDetails.State;
        userMicroserviceModel.Country = userDetails.Country;

        if (Int32.TryParse(userDetails.ZipCode, out int zipCode))
        {
            userMicroserviceModel.ZipCode = zipCode;
            Console.WriteLine("Updated zip code");
        }
        else
        {
            Console.WriteLine("String could not be parsed.");
            return HttpStatusCode.BadRequest;
        }

        var jsonString = JsonSerializer.Serialize<UserMicroserviceModel>(userMicroserviceModel);
        var payload = JsonSerializer.Serialize(userMicroserviceModel);
        var content = new StringContent(payload, Encoding.UTF8, "application/json");

        var response = await _client.PostAsync(_apiGatewayDev, content);
        return response.StatusCode;
    }  
}

GitHubréférentiel

Pour une implémentation complète de l'exemple d'architecture pour ce modèle, consultez leGitHubdépôt surhttps://github.com/aws-samples/anti-corruption-layer-pattern.

Contenu connexe