INFOTEL VOUS REMERCIE POUR VOTRE CANDIDATURE

Un chargé de recrutement prendra contact avec vous prochainement.

Décryptage métier : Architecture logicielle

Être architecte logiciel en 2018

Être architecte logiciel en 2018

Vous trouverez dans cet article les points essentiels qui ont été évoqués lors de la conférence Devoxx.

 

Qu’est-ce que l’architecture ?

Il y a plusieurs définitions d’architecture, mais celles-ci ne sont pas très claires…

« C’est tout ce qui est important. »

« Les décisions de design significatives qui façonnent le système. »

« Toutes les choses difficiles à changer. »

 

L’architecte

Aujourd’hui nous avons trois types d’architectes. Ceux qui sont officiellement désignés par leur hiérarchie. Ils apportent en général des théories et des solutions pour des problèmes à l’échelle du SI d’une entreprise.

Il y a ceux qui le sont par la pratique, car ils sont sur un projet et participent au sein d’une équipe au développement.

Enfin, le troisième type correspond à tout le monde, lorsque nous sommes seul à développer sur une application, nous sommes l’architecte de nous-même.

Dans les projets d’aujourd’hui, les managers veulent toujours faire des projets de plus en plus gros, avec le maximum de technologies. Ils sont également encouragés par les développeurs qui souhaitent assouvir leur soif de nouveautés.

L’architecte doit comprendre le problème et faire redéfinir le besoin pour choisir les technologies les mieux adaptées tout en simplifiant au maximum l’architecture.

 

Domaine Driver Design

Dans la conception d’un logiciel, le découpage de celui-ci est important pour assurer sa lisibilité et sa maintenabilité. Mais comment devons-nous la découper ?

Dans une architecture classique « Front, Back (Logic), DAO, DB » nous constatons une multitude d’appels réseaux entre les stacks. Pour chaque appel, nous avons un échange sur l’ensemble des stacks, de l’utilisateur à la base de données. Nous pouvons, sur cette architecture, rencontrer des problèmes de performances à cause des échanges entre les stacks.

Si nous souhaitons découper par technologie, il est possible qu’il y ait un fort couplage.

Pour un découpage par entité, comme avec les microservices ? Le problème est que nous aurons toujours besoin d’un produit pour constituer un panier et faire une commande. Il y aura donc beaucoup d’échange entre les services d’entité.

Un bon découpage est de le faire par fonctionnalité (Domain). Il permet de regrouper les fonctions qui vont ensemble et de limiter les dépendances entre les packages.

Cette solution nécessite la création d’adaptateur (ou mapper) pour copier des attributs d’un objet d’une classe vers un objet d’une autre classe. Ce sont eux qui font les liens et sont appelés au niveau des services. La solution nécessite également l’écriture de requêtes complexes et de sélectionner uniquement les champs utiles.

Ce découpage part du principe que chaque domaine à des besoins différents et il permet de définir une solution en fonction du besoin. Faire le choix d’utiliser une base de données, un PIPE, un batch, etc. Enfin, nous aurons donc un logiciel par domaine.

 

Les contrats

Pour une application, un contrat est créé lorsqu’un de ces composants ou produit est utilisé par une autre application.

Ne pas permettre la compatibilité donne l’opportunité au client de changer de fournisseur.

On ne modifie pas les contrats. On peut être tolérant sur ce qu’on reçoit mais on est rigoureux sur ce qu’on émet.

C’est-à-dire qu’on ignore ce qu’on ne connaît pas, on ne supprime ou ne modifie pas de fonction pour garder la rétro-compatibilité. Si nous souhaitons faire évoluer les données échangées sur un service, nous créons un nouveau service.

Il est cependant nécessaire de véhiculer la version des services pour savoir si une information doit être présente ou non.

Nous devons donc orienter nos choix de technologie, selon ce principe.

Il est également important de bien isoler les schémas d’une base de données et de ne pas créer d’adhérence avec une autre application. Si deux applications utilisent la même base de données il y a donc un contrat entre ces deux applications. Celui-ci correspond à la base de données elle-même. Faire évoluer une application nécessitera de faire évoluer la seconde ou de migrer vers une nouvelle base de données.

 

Une unique source de vérité

Afin d’éviter de créer des contrats entre applications, nous serons tentés d’effectuer des copies de données d’un domaine vers un autre domaine.

Si nous le faisons, il faudra s’assurer qu’uniquement les données utiles sont recopiées et que celles-ci ne sont pas modifiées dans l’environnement cible.

Si une application doit modifier une donnée, elle devra faire appel à un service du domaine source pour modifier une donnée puis recevoir, du domaine source, sa copie à jour.

Cette pratique permet d’éliminer le risque d’une désynchronisation des données et de toujours avoir une unique source de vérité.

 

Le choix des technologies

On demande souvent de faire le choix des technologies au début alors que c’est à ce moment que nous avons le moins de connaissances. Il est recommandé d’attendre que le besoin se précise ou de faire un choix qui ne bloquera pas l’évolution.

Dans tous les cas, nous devons utiliser des technologies éprouvées qui permettent d’éviter des problèmes futurs. Il faut également prendre en compte l’environnement, la culture de l’entreprise et le savoir-faire des intervenants.

 

Par Geoffrey C.