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.

banque

Banque

Traitement automatisé des demandes de prêt et simplification du KYC "Know Your Customer".

Fonctionnement

  • Amélioration du KYC et embarquement des clients en vérification automatiquement l'identité des nouveau clients grâce au traitement intelligent des documents d'identité sur le web ou dans une application.
  • Accélération des demandes de prêts et d'hypothèques : traitement et classification automatique des documents entrants, extraction des informations et validation des points de données.
  • Prévention de la fraude et respecte des règles : automatisation des contrôles de conformité réglementaire sur les contrats, les documents financiers et les documents d'identité.
  • Facilitation et simplification de la compréhension des dépenses des consommateurs : classification des transaction bancaires en lisant les données des postes de reçus et de factures.
Brevets

Brevets

Traitement automatisé des documents scientifiques et autres documents liés au dépôt de brevet pour la propriété intellectuelle.

Fonctionnement

  • Reconnaissance et indexation automatique des champs pour une recherche précise parmi les documents relatifs au dépôt de brevet.
  • Uniformisation des documents en lien avec les spécifications qui sont ainsi mis à jour : bibliographie, brevet expiré, brevet renouvelé, etc.
Comptabilité

Comptabilité

Traitement automatisé des reçus, factures et autres documents financiers etc.

Fonctionnement

  • Automatisation des processus comptable : réconciliation des comptes bancaires, déclaration de TVA, saisie des factures fournisseurs.
  • Standardisation et harmonisation des processus comptables de l'entreprise.
  • Sécurisation de la qualité des données en supprimant les erreurs manuelles et en synthétisant les contrôles.
  • Contribution à la réduction des risques de fraude, renforcement de la sécurité des opérations, la pise d'audit et le contrôle interne.
  • Accompagnement dans la conduite du changement et des équipes comptables sur l'appropriation de cette nouvelle solution.