Publié par
Il y a 1 année · 13 minutes · Back, Craft

Pérennisez votre métier avec l’architecture hexagonale !

Dans la majorité des DSI où nous intervenons, nous faisons souvent le même constat depuis plusieurs années ; il reste difficile de produire des applications évolutives et pérennes. C’est d’autant plus vrai aujourd’hui alors que la révolution numérique (ne dites surtout pas digitale) bat son plein, entrainant des nouveautés incessantes en termes de technologies, d’outillage, etc. Ainsi, il est assez courant d’entendre que la durée de vie d’une application ne dépasse pas 4-5 ans et toute ou partie de la connaissance métier se perd après chaque redémarrage à zéro, malgré toute la bonne volonté du monde.

Plus précisément, nous observons chez nos clients :

  • Des choix techniques précipités. Ces derniers sont la majorité du temps faits au début du projet, alors que la connaissance est à son niveau le plus faible (volume d’utilisateurs, pics de charge, adéquation aux contraintes métier). C’est un pari sur le futur qui s’avère souvent désastreux et se fait au détriment de la connaissance métier, qui elle aussi est à son niveau le plus bas.

Learning time graph

  • Un immobilisme technique. Une fois ces choix techniques faits, il est souvent difficile voire impossible de s’en défaire. Cela nécessite la plupart du temps de re-tester le périmètre complet de l’application et induit un très fort risque de régressions. Plus le temps passe, plus l’application grossit et plus l’immobilisme grandit jusqu’à atteindre un point de non-retour. Ce problème trouve son origine dans l’incapacité des équipes à séparer la logique métier des technologies, frameworks et outils utilisés.
  • Une faible testabilité de la logique métier. Ne pas séparer la logique métier de l’infrastructure n’a pas que des impacts techniques. Dans bien des équipes, les tests fonctionnels font intervenir un grand nombre de couches techniques (bases de données, middlewares). De ce fait, ils sont souvent longs à s’exécuter, le sont rarement (au mieux une fois par jour) et sont friables. Au final, ils sont souvent rares voire même abandonnés car la boucle de feedback est trop longue et trop difficile à mettre en place. En conséquence, les testeurs (ou QA) perdent la majorité de leur temps à répéter manuellement des tests qui pourraient être automatisés, réduisant ainsi la part exploratoire de leur travail. Ceci n’est évidemment pas sans conséquence sur la qualité finale de l’application.

Pour faire face à ces problèmes, il convient de faire usage d’une approche isolant logique métier et couches techniques.
Chez Xebia, nous pensons que c’est essentiel afin :

  • d’assurer la pérennité du métier de son application (les technologies doivent pouvoir changer sans risque de régression) ;
  • de renforcer l’appétence des équipes au métier, voie royale vers une plus grande qualité et une plus grande adéquation des livrables aux besoins clients.

Dans cet article, nous vous proposons de découvrir l’une de ces approches : l’architecture hexagonale.

Complément d’information

Il nous parait important de mentionner que cet article trouve son inspiration dans de multiples sources comme cette excellente présentation faite à Devoxx’ 15 par Cyrille Martraire et Thomas Pierrain. Il ne se veut en aucun cas une retranscription de cette dernière mais un partage de connaissance quant à son usage intensif depuis 2 ans sur l’un des projets où nous intervenons.

Origines

L’architecture hexagonale est ce que l’on pourrait appeler un pattern d’architecture. Il a été introduit sous ce terme par Alistair Cockburn au milieu des années 2000 et a été ensuite renommé en « Ports & Adapters ». Depuis, bon nombre d’auteurs ont publié des patterns semblables dont Uncle Bob (Clean Architecture) et Jeffrey Palermo (Onion Architecture).  Les concepts que nous allons détailler dans cet article s’appliquent bien souvent à l’ensemble de ces variantes.

Concepts

L’architecture hexagonale repose sur une idée très simple : isoler la logique métier des détails techniques de son implémentation.
Il existe un dedans (le métier ou modèle) et un dehors (les détails techniques ou infrastructure).

L'architecture hexagonale repose sur une idée très simple : isoler la logique métier des détails techniques de son implémentation. Il existe un dedans (le métier ou modèle) et un dehors (les détails techniques ou infrastructure).

Le principe fondateur de ce pattern est que le métier ne dépend de rien. C’est donc l’infrastructure qui dépend du métier.
Autrement dit, toutes les dépendances vont de l’extérieur vers l’intérieur, sans exception.
Une fine couche d’adaptation, contenue dans l’infrastructure, se charge de faire le lien entre les deux mondes.

adapteurs architecture hexagonale

 

Un modèle agnostique de l’infrastructure

Le modèle ne contient aucune référence technique. Vraiment aucune. En d’autres termes, il ne contient pas de framework, pas de base de données, pas de middleware, pas d’accès réseaux, pas d’écriture/lecture sur disque, pas d’annotations liées à un ORM, etc. Le modèle, c’est un langage nu et c’est tout ! Il ne doit jamais y avoir une dépendance du modèle vers l’infrastructure.

Le modèle expose des interfaces qui ont un sens métier.
On trouve d’une part des interfaces exposées pour les composants ayant besoin d’invoquer le modèle. On parle d’API (Application Provider Interfaces).


API (Application Provider Interfaces)

Et d’autre part, des interfaces exposées pour les composants que le modèle a besoin d’invoquer. On parle de SPI (Service Provider Interfaces).

SPI (Service Provider Interfaces)

Comme ces interfaces font partie du modèle, elles ne doivent contenir aucune sémantique liée à l’infrastructure.
Elles doivent absolument avoir un sens métier.

Une infrastructure qui s’adapte

Nous l’avons vu précédemment, le métier ne dépend jamais de l’infrastructure. C’est cette dernière qui dépend du métier et se doit de s’adapter.
Autrement dit, si nous changeons de type de base de données, nous n’aurons qu’à changer un adaptateur et nous n’aurons pas à toucher notre couche métier.

Toutes les dépendances vont donc de l’extérieur vers l’intérieur. Pour les composants qui appellent notre métier, c’est facile. Ils n’ont qu’à contacter nos API.
Mais quid des fournisseurs que notre métier va avoir besoin de contacter ? Comment faire en sorte que notre modèle n’en ait pas connaissance ?

La réponse est relativement simple. Nous allons faire usage d’un principe SOLID, le « Dependency Inversion Principle » (DIP).

usage d'un principe SOLID, le « Dependency Inversion Principle » (DIP).

L’idée est que notre modèle ne connaisse qu’une interface ayant un sens purement métier. L’implémentation ne sera résolue qu’à l’exécution et c’est le rôle de l’adaptateur que de la fournir. Si notre technologie sous-jacente change, l’implémentation de l’interface changera également mais ce sera transparent pour notre modèle. On obtient ainsi une forte cohésion de notre métier et un faible couplage entre les deux couches (« Low coupling, high cohesion »).

Au final, l’architecture de notre application aura la forme suivante :

les deux couches (« Low coupling, high cohesion »)

Les composants souhaitant communiquer avec notre métier le feront au travers d’adaptateurs qui contacteront nos API. Leurs implémentations font partie de notre modèle et ne sont pas visibles à l’extérieur de l’hexagone.
À l’inverse, les composants avec lesquels notre métier souhaite communiquer seront contactés au travers des SPI dont les implémentations seront résolues à l’exécution et fournies par des adaptateurs.

Gains

Une testabilité du métier accrue

Les concepts que nous venons de voir permettent de séparer le métier de l’infrastructure.  Ainsi, si nous souhaitons tester notre métier, nous n’avons qu’à nous occuper de la couche du modèle. Et c’est un gain considérable ! Nos tests ne dépendent plus d’une base de données, d’un middleware ou de lectures/écritures sur disque ; ils se trouvent donc sensiblement accélérés ! Il suffit d’envoyer un message sur une API et de brancher une implémentation de test (fake, stub, mock) sur l’une des SPI. Et le tour est joué !

En conséquence, la boucle de feedback est extrêmement rapide ; la non-régression est assurée quasi-instantanément. De ce fait, la couverture métier est plus aisée et devient généralement plus large. En résulte une facilité à tester qui permet de délester les testeurs de leurs tâches répétitives pour les laisser se concentrer sur les tests exploratoires. C’est un cercle vertueux qui aboutit généralement à une qualité accrue des livrables.

Une pérennisation du métier face aux changements techniques

Puisque le métier est séparé des détails d’infrastructure, un changement technique n’a plus aucun risque d’introduire une régression fonctionnelle.
Ainsi, il devient aisé :

  • de changer de solution technique lorsque celle-ci n’est plus adaptée (augmentation du nombre d’utilisateurs par exemple) ;
  • de tester une nouvelle solution qui parait prometteuse (et ce, en parallèle de l’existante).

Le changement n’est plus source de peur et l’application n’est plus figée dans ses choix techniques initiaux. D’autre part, le métier de l’application est pérennisé. Cela ne veut pas dire qu’il n’évolue pas mais il ne subit plus la loi des changements techniques. Ainsi, la durée de vie des applications s’allonge et les connaissances métiers acquises sont capitalisées.

Une capacité à livrer de la valeur rapidement

Au démarrage d’une application, l’usage de l’architecture hexagonale permet de démontrer rapidement puisque l’on ne dépend plus de contraintes extérieures comme l’infrastructure.
On peut aisément remplacer une base de données par un fichier plat ou une application web par une ligne de commande et cela suffit amplement à proposer un MVP au bout du premier sprint. On repousse ainsi les choix techniques à plus tard, au moment où notre connaissance sera plus à même de faire un choix éclairé. Mieux, on se concentre sur le besoin client (le métier) et l’on accélère la boucle de feedback pour s’assurer que l’on se trouve sur la bonne voie.

Et mon modèle en couches alors ?!

L’une des questions les plus fréquemment posées à propos de l’architecture hexagonale est : « quelle est la différence avec un bon vieux modèle en couches ? »
Arrêtons-nous quelques instants pour tenter d’y répondre. Traditionnellement, beaucoup d’applications sont architecturées selon trois couches :

beaucoup d'applications sont architecturées selon trois couches : présentation, métier, persistence

(Credits schéma - http://matteo.vaccari.name/blog/archives/154)

Généralement, la couche présentation ne connait que la couche métier qui elle même ne connait que la couche de persistance. Si les choses ont été bien faites, une couche ne connait pas l’implémentation de la couche dont elle dépend via l’usage du « Dependency Inversion Principle » (DIP). C’est l’usage de ce principe qui laisse à penser qu’il existe une équivalence entre les deux architectures alors que la différence est bien marquée.

Posons-nous la question suivante : « où se situe notre logique métier dans cette architecture traditionnelle en couches » ? Intuitivement, on pourrait penser qu’elle se trouve dans la couche du même nom.
Or, cette dernière contient la plupart du temps des services sans état qui travaillent sur les entités venant… de la couche de persistance ! Du coup, notre métier est partagé entre la couche métier et la couche de persistance.

Pire, les entités de cette dernière sont souvent complétées d’annotations liées à un ORM (ce qui représente un détail d’infrastructure) et sont anémiques, c’est à dire sans comportement. On pourrait être tenté de regrouper ces deux couches mais on se retrouve alors à mélanger logique métier et détails d’implémentation et l’on en revient aux problématiques énoncées au début de cet article.

À l’inverse, si l’on regarde l’architecture hexagonale sous une vue « en couches », voici ce que l’on obtient :

on regarde l'architecture hexagonale sous une vue « en couches »

(Credits schéma - http://matteo.vaccari.name/blog/archives/154)

Le métier ne dépend de rien et les autres couches dépendent du métier. Contrairement à une architecture en couches traditionnelle, état et comportement sont co-localisés bien à l’abri des détails techniques de l’infrastructure.

Nos conseils pour faire un usage pragmatique de l’architecture hexagonale

Faites vivre votre modèle métier

Pérenniser votre métier ne signifie pas le figer dans le marbre. N’oubliez jamais que votre modèle représente votre connaissance à un instant T.
Il convient donc de l’enrichir, de le faire évoluer dans le temps et de montrer une réelle appétence pour le métier que vous supportez au travers d’une communication riche et d’un langage partagé avec les experts. Des pratiques comme le « Behavior Driven Development » (BDD) et le « Domain Driven Design » (DDD) vous y aideront. Notez que l’utilisation de l’architecture hexagonale facilite grandement leur mise en place même si elle n’est pas systématique.

Prenez soin de vos interfaces

Les objets contenus dans vos interfaces font partie intégrante de votre modèle et il convient d’y porter une grande attention. Prenez garde à ce que les interfaces et leurs objets gardent un sens purement métier. Veillez à ne pas ajouter de complexité accidentelle dans votre hexagone ; fuyez les chaines de caractères, favorisez les types forts et les énumérations. 

Les objets contenus dans vos interfaces font partie intégrante de votre modèle

Ne tentez pas d’absorber toute la variété métier disponible à l’extérieur de l’hexagone mais construisez un modèle cohérent.
Gardez en tête que ces interfaces et objets vont évoluer au cours du temps pour permettre la mise en œuvre de nouvelles fonctionnalités.

Commencez toujours par le cœur de votre hexagone

Un exercice intéressant consiste à développer l’ensemble de votre hexagone avant de vous attaquer aux détails techniques.
Pour ce faire, laissez-vous guider par les tests (BDD) et remplacez temporairement l’infrastructure par des mocks, stubs ou fakes.

À l’arrivée, vous obtiendrez un modèle bien plus cohérent, nettoyé de tout détail technique puisque ne communiquant que via ses API et SPI « métier ».
Ce dernier sera dans bien des cas suffisant pour démontrer à votre client et ainsi obtenir un premier feedback sur l’adéquation de votre travail.

Vous pourrez par la suite renforcer la séparation métier/infrastructure en créant par exemple des modules séparés.
C’est un excellent moyen pour éviter toute dépendance malencontreuse du métier vers les détails techniques.

N’utilisez pas l’architecture hexagonale à toutes les sauces

Comme tout pattern ou pratique, il convient de faire preuve de pragmatisme. L’architecture hexagonale n’est pas conseillée dans certains cas, notamment si votre application est un composant purement technique, dénué de toute logique métier. Pour le savoir, posez-vous la question suivante : « si telle ou telle technologie change, est-ce que mon composant continue d’exister » ? Si la réponse est non, ne vous embêtez pas à construire un hexagone. Dans le cas contraire, interrogez-vous ; votre application pourrait bien contenir un métier dont vous ignoriez l’existence…

Plus généralement, l’architecture hexagonale est conseillée si votre métier est riche et/ou complexe. Elle favorise les pratiques telles que le BDD, le DDD et l’appétence au fonctionnel en général.
Mieux, elle peut être répétée dans plusieurs composants communiquant les uns avec les autres (qui a dit bounded contexts ?!).

Elle favorise les pratiques telles que le BDD, le DDD et l'appétence au fonctionnel en général.

TL; DR

Dans cet article, nous avons présenté l’architecture hexagonale pour répondre à trois constats observés sur le terrain par nos consultants :

  • des choix techniques précipités ;
  • un immobilisme technique ;
  • une faible testabilité de la logique métier.

Nous avons vu comment, en séparant métier et infrastructure, ce pattern offrait :

  • une testabilité du métier accrue ;
  • une pérenisation du métier face aux changements techniques ;
  • une capacité à livrer de la valeur rapidement.

Enfin, nous vous avons donné quelques conseils pour une mise en œuvre pragmatique.
Dans un prochain article, nous vous proposerons des exemples d’implémentation pour concrétiser la partie théorique abordée dans celui-ci.

Clément Héliou
Pragmastism Driven Developer passionate about xDD (TDD/BDD/DDD), clean architectures (Event Sourcing, Hexagonal Architecture and al.) and code quality. Enthusiastic defender of knowledge sharing and human skills.

19 réflexions au sujet de « Pérennisez votre métier avec l’architecture hexagonale ! »

  1. Publié par Fabien, Il y a 1 année

    Par conséquent, vu que ce n’est plus la couche métier qui appelle la persistance, qui alimente la couche métier et écrit les résultats ?

  2. Publié par Clément Héliou, Il y a 1 année

    Bonjour Fabien,

    Pouvez-vous me donner un exemple concret pour que je puisse répondre précisément à votre question?

    Si j’ai bien compris votre question, vous cherchez à savoir comment s’articule l’architecture hexagonale pour récupérer les résultats d’une requête sur votre système de persistance.

  3. Publié par Fabien, Il y a 1 année

    Dans une architecture classique Présentation -> Métier -> Persistance , c’est bien souvent la couche métier qui va chercher les données dont elle a besoin et qui les remet à jour en base de données.

    Par exemple, admettons que dans ma présentation j’ai un bouton « Invalider les permis sans point ».
    On appelle une fonctionnalité de la couche métier qui va :
    – aller chercher les permis sans dans la persistance
    – les mettre « invalide »
    – mettre à jour les permis sans dans la persistance

    Je suis tout à fait d’accord pour dire que cela finit par introduire du métier dans la persistance et complique les tests de la couche métier.

    Du coup, avec cette architecture hexagonale, je suppose que la couche métier se contentera d’avoir une liste de permis en paramètre (toute la base ?), trouver ceux qui sont sans point et setter le flag invalide.

    Dans cette vision, qui va chercher les permis en base avant de les envoyer au métier ?
    Une fois l’opération effectuée, qui va mettre les permis modifiés dans la persistance ?

    Faut-il une autre couche entre la présentation et le métier qui s’occupe de la persistance avant et après le traitement de la couche métier ?

  4. Publié par Fabian Piau, Il y a 1 année

    Intéressante lecture!
    Est ce une erreur de dire que l’architecture hexagonale est plus adaptée à une application monolithique qu’à une architecture orientée microservices?

  5. Publié par Clément Héliou, Il y a 1 année

    @Fabian

    Cela me parait en effet inexact.
    L’architecture hexagonale est orthogonale à ces concepts.

    Ce qui va changer, c’est la taille du domaine. Comme le laisse deviner la dernière illustration, on peut avoir un hexagone sur chaque micro-service. Et là, le lien avec les Bounded Contexts de DDD arrive naturellement.

    Dans le cas où vous ne faites pas usage de l’architecture hexagonale, il parait évidemment plus simple de recoder un micro-service qu’une application monolithique. Mais c’est, selon moi, un mauvais calcul car même éparpillé et réduit à sa plus simple expression, le métier doit être pérénisé.

  6. Publié par Clément Héliou, Il y a 1 année

    @Fabien

    La question à se poser ici est « où se trouve mon métier ? »
    Dans votre cas, il me semble qu’il s’agit de la règle déterminant qu’un permis est invalide (i.e. s’il n’a plus aucun point).

    Du coup, j’aurais une API qui prend une liste de permis. Elle pourrait être appellée:
    – soit par un adapteur faisant le lien avec la couche de présentation (cas d’usage via une GUI, où l’on invalide une liste de permis affichée);
    – soit par un adapteur faisant le lien avec la couche de persistance (cas d’usage via un batch, où l’on invalide la liste de tous les permis en base);

    Son implémentation filtre les permis selon la règle métier et appelle une SPI avec la liste obtenue en sortie. C’est l’implémentation de cette dernière (i.e. un adapteur) qui va déterminer ce qu’il faut faire; à savoir persister cette liste en base via une requête d’update.

  7. Publié par ouarzy, Il y a 1 année

    Bonne entrée en matière, merci. J’ai juste un peu tilté quand tu dis que ca evite les modèles anémiques car on sait ou mettre le metier. Dans une application en couche classique aussi on est censé savoir ou va le métier. Pourtant on le place mal. Tu as le même problème dans une archi hexagonal, il est toujours possible de mettre de la logique metier dans les adapter, et de garder un modèle anémique (meme si l’ORM ne leak plus directement sur ton modèle)

    En gros ca interdit des aberrations technique, mais on ne peut pas interdire des aberrations logiques.
    @+

  8. Publié par Thomas PIERRAIN, Il y a 1 année

    Suis d’accord avec Ouarzy, j’ai recemment vu une appli ou une grosse partie de la logique métier s’etait retrouvée dans les adapters. Adapters dans lesquels l’architecte technique un peu old school avait mis un patron de méthode pour que ses collegues puissent rajouter plus facilement la logique métier (il etait donc passé completement a coté du pattern hexagonal ;-)

  9. Publié par Clément Héliou, Il y a 1 année

    @Dan J’ai rajouté hier un lien vers cette conférence qui est effectivement excellente et qui a été une source d’inspiration à chaque fois que j’ai eu à vanter l’architecture hexagonale (cf. ce tweet https://twitter.com/c_heliou/status/694591500370497536). Et Dieu sait que je le fait que ce soit chez Xebia ou dans le cadre de ma mission (où nous utilisons cette architecture quotidiennement depuis 2 ans). C’est une regrettable erreur de ma part que de ne pas l’avoir fait plus tôt.

    @ouarzy @Thomas
    « En gros ca interdit des aberrations technique, mais on ne peut pas interdire des aberrations logiques.»

    Tout est dit!

  10. Publié par Bernard Chabot, Il y a 1 année

    De quelle manière modélisez vous le métier dans une approche hexagonale ? Utilisez-vous des DSL (Domain Specific Language), des ontologies (OWL), … ?
    Et de quelle manière le testez-vous ?

  11. Publié par Clément Héliou, Il y a 1 année

    @Bernard

    Pour modéliser le métier, j’utilise certains patterns du Domain Driven Design (DDD) et les couple parfois à de l’Event Sourcing. Néanmoins, rien ne vous empêche de faire autrement si vous estimez que c’est plus pertinent, tant que vous respectez l’isolation du métier.

    En ce qui concerne les tests, je me base exclusivement sur le Behavior Driven Development (BDD) qui est facilité par le fait que toute l’infrastructure n’entre pas en jeu dans le cadre des tests.

  12. Publié par Aurélien, Il y a 11 mois

    Bonjour,

    Merci pour cet excellent article !

    Dans le modèle en couche on « s’amuse » à créer des adapteurs pour chaque POJO qui traverse les trois couches. On retrouve parfois certains POJO dupliquer à l’identique mais portant un nom différent en fonction de la couche où il se situe.

    Est ce que dans l’architecture hexagonale, il faudrait également systématiquement dupliquer un POJO du domain par POJO de l’infra dont l’adapteur s’occuperait de copier le contenu ?

    D’avance merci pour votre réponse.

  13. Publié par Clément Héliou, Il y a 11 mois

    Bonjour Aurélien.

    Ta question est pertinente et revient souvent lorsque l’on commence à implémenter l’architecture hexagonale.

    L’objectif poursuivi est de n’avoir aucun détail technique (transport + protocoles de sérialisation) à l’intérieur de l’hexagone. Pour ce faire, il faut donc créer un modèle métier que les adapteurs se chargeront de traduire.

    Il arrive bien souvent que ce modèle ressemble fortemment à celui de l’infrastructure d’où parfois un sentiment de « duplication » (mapping 1 à 1). Mais, à mon avis, cette vue est incomplète. Il faut considérer la « duplication » versus la maintenabilité obtenue en ce faisant.

    Au final, libre à chacun de placer le curseur où bon lui semble mais attention à ne pas aller trop loin et perdre les bénéfices de ce type d’architecture. Si la tâche s’avère pénible, il existe des librairies qui peuvent aider comme Selma (http://www.selma-java.org/).

  14. Publié par Marc Gardent, Il y a 9 mois

    « Le principe fondateur de ce pattern est que le métier ne dépend de rien. C’est donc l’infrastructure qui dépend du métier. »

    « toutes les dépendances vont de l’extérieur vers l’intérieur, sans exception. »

    « (…) Et d’autre part, des interfaces exposées pour les composants que le modèle a besoin d’invoquer. On parle de SPI (Service Provider Interfaces). »

    C’est à dire que le fondement du pattern est remis en cause par le pattern lui-même : *les SPI sont des dépendances* à l’hexagone métier.

    l’ archi. hexagonale est systématiquement perverti dès que nous avons besoin de faire des contrôles sur une masse de données importantes.

    Par exemple, vérifier l’unicité d’un login pour sa création est une logique métier qui sera assuré par une base de données : autrement dit la logique de mon métier est fourni par un tiers. Et les exemples ne manquent pas.
    Cet écueil est existant dans toutes les archi. qui essaye de séparer métier et la DB.

    – Les Gains –

    « Une testabilité du métier accrue »

    Je reste convaincu que le principe de ne pas mélanger du code infra et du code logique, est du bon sens – possible dans tous les autres architectures. Et ceci est une condition nécessaire pour une bonne testabilité.

    « Une pérennisation du métier face aux changements techniques »

    Enfin c’est les abstractions bien construites et non vraiment l’archi elle-même qui le permet.

    « Au démarrage d’une application, l’usage de l’architecture hexagonale permet de démontrer rapidement puisque l’on ne dépend plus de contraintes extérieures comme l’infrastructure. »

    Pouvons-nous réfléchir à ce que je vais pouvoir montrer à la direction à part du code source ??! ma couche métier démontre rien du tout! et pour le reste c’est du code infra !!

    Par contre l’usage des abstractions permet de faire des bouchons pour réaliser un prototype rapidement tout en restant dans la continuité d’un vrai futur logiciel en prod.

    – Le clou du spectacle! –

    Si nous dessinons la callstack d’un cas utilisation banal nous pouvons constater qu’il y a aucune différence qu’avec une archi en couche!!! @@ plop.
    http://www.duncannisbet.co.uk/wp-content/uploads/2012/07/2012-07-11-13.42.44.jpg

    Tout ceci pour dire qu’il y a de bon principes mise en avant. Mais je ne trouve pas de critères objectifs pour en faire une archi. à part entière.

    J’espère trouver des compléments d’information, tant la promesse est grande – je ne veux rater quelque chose d’aussi fameux!

    En tout cas j’adhère à 100% au principe mise en avant.

  15. Publié par neolao, Il y a 8 mois

    Pourquoi on représente un hexagone alors qu’au final, il n’y a que 4 côtés qui sont utilisés ?
    Les schémas fonctionnent avec un carré. Sauf s’il y a une autre subtilité et que les côtés du haut et du bas servent à désigner quelque chose.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *