Bonjour, je suis Thomas Pierrein, Thomas bonjour.
Salut Benoît.
J'espère que tu vas bien.
Ça fait bizarre de te dire ça alors que ça fait 3,5 heures qu'en échange.
C'est un jeune épisode de podcast.
Surtout qu'aujourd'hui tu représentes Agica, qui est sponsor de cet épisode.
Merci les gars de votre attention.
Est-ce que tu peux nous dire quelques mots sur ce que tu fais, qui tu es, deux mots sur
Agica aussi.
Alors, je suis Thomas Pierrein, ça fait 24 ans que je fais du logiciel pour vivre.
Je suis chez Agica depuis le mois d'octobre dernier en tant que VP of Engineering.
Et pour accompagner aussi Lucla qui est CTO, Lucca Bartola qui est un des co-fondateurs
avec CTO.
Et donc je m'occupe de la tech de manière générale.
Donc je code pu depuis octobre, je fais un peu de mode de temps en temps, mais je m'occupe
des gens et de l'organisation et de comment on fait pour être une tech efficace dans une
scale-up.
Quel sujet du jour ?
Ah, le sujet du jour, on s'est dit qu'on parlerait bien de découpe de monolithes à
la découpe.
Oui.
Parce que voilà, c'est un sujet à mon avis qui peut intéresser pas mal de gens, je le
vois dans les confs.
Ah ben je pense que ça, je sais pas où ça en est parce que c'est vrai que j'avais
l'impression que c'était un sujet, mais il y a un an ou deux peut-être, que c'était
plus forcément un sujet d'actualité, mais peut-être que je me trompe, un peu en réaction
à cette vague de texte, d'overdose de microservice, où je voyais des équipes démarrées, de buts
en blanc avec 40 microservices, et je leur disais les gars, mais vous allez dans le mur
en fait.

Et moi j'avais toujours eu cette approche un peu, alors qu'il était justement dans
cette période-là à contre-courant, on dirait que le mieux c'est quand même de démarrer
par un monolithe parce que tu vas quand même pas trop vite, et puis tu découpes aux
besoins.
Alors comment est-ce que tu vois les choses de ton côté toi ?
Alors je suis complètement aligné avec toi.
J'avoue que la première vague de mode des microservices est donnée un peu du
urticar. J'ai toujours été fan d'architecture orientée service, donc j'ai toujours fait
vraiment des services, mais ce n'était pas des microservices au sens des ce qu'on appelle
maintenant des macroservices, je pense qu'il y a un retour de bâton, c'est après trop de
micros, trop de réseaux.
Après moi j'ai travaillé beaucoup dans les systèmes distribués, et donc quand tu travailles
dans les systèmes distribués, tu apprends qu'il y a beaucoup d'illusions, on se fait
beaucoup d'illusions en tant que dev, les fallacies au distributile computing, que le
réseau est fiable, que la temps ne existe pas, que la vente passante est limitée.
Alors moi j'ai un souvenir marquant, ça a été une de mes spécialités à l'école
d'ingénieur, et ça ne doit pas dire plus de 20 ans, j'ai pris une option application
distribuée, la première règle qu'on t'apprend, c'est si vous pouvez vous en passer, ne
faites pas ça.
Il y a 20 ans, on est déjà au rence du...
C'est ça, en fait on apprend pas beaucoup, et quand j'ai eu la mode de microservice,
disons que ça avait l'air plus élégant, puis les gens se sont un peu, se sont jeter
rues et dessus, alors moi j'étais un peu, bon j'étais un peu sceptique pour toutes
ces raisons là, mais plutôt fan de l'approche effectivement monolithe modulaire pour tout
un tas de raisons.
Alors c'est vrai que quand j'ai rejoint G-CAP, donc c'est une scale-up en pleine
croissance, etc, le nombre d'équipes qui augmente, le nombre de sujets qui augmente
et tout, tu as quand même besoin de bien clarifier ta code base et tout.
Donc aujourd'hui chez G-CAP, il nous reste un monolithe, et c'est sur celui-ci, autant
les nouveaux sujets très souvent, ils viennent émerger sur des nouvelles API ou des nouveaux
blocs fonctionnels, autant le monolithe on essaie de le découper parce que pour l'instant
en termes de release management, ça peut...
En fait quand tout va bien, quand t'as un monolithe modulaire, c'est-à-dire bien rangé,
c'est comme si toutes les équipes de dev habitait dans le même immeuble qu'une co-pro,
et que chacun habite à son étage, et que chacun est autonome, t'as l'eau, t'as
l'électricité, tout va bien quoi.
Quand c'est mal fait, quand t'as un monolithe qui n'est pas complètement modulaire, c'est
comme si tu dois aller faire ta vaisselle dans l'appartement du dernier étage, tout
en d'abord aller chercher l'eau au deuxième et puis prendre tes douches dans la cave commune
par exemple, etc. En plus, à mon avis, à chaque fois tu te refiles la clé ou tu dois
aller chercher la clé entre locataire, en demandant la permission, etc.
Enfin ça ressemble...
En termes d'efficacité, ça ressemble un peu plus à ça.
Donc monolithe oui, mais modulaire surtout.
Donc tout l'enjeu pour nous, c'est vraiment modulaire.
Ça a été ça, je pense que le miroir aux alouettes des gens, c'était de se dire
comme ça sera découpé, ça sera plus possible en fait, parce que ce que tu décris n'est
plus possible dès lors que tu as des bâtiments séparés en fait.
Mais il n'a plus juste à vue que la complexité allait les chopper de revers ailleurs.
Clairement, je ne sais pas, il y avait Simon Brown, tu vois qui c'est, archi anglais, bien
sympathique, qui fait pas mal de taux, qui avait presque même une époque sur un des
trucs qui sorti en conférence, qui était en gros, t'apparais si à faire un monolithe
correctement, qu'est-ce qu'il te fait croire que tu vas réussir en faisant du micro service.
C'est ça, tu rejeux du réseau.
Tu sais pas, architecture un monolithe comme il faut, tu n'essayes pas de faire du micro
service, tu vas...
Ah non, effectivement, le fait de travailler sur la modulisation du monolithe, c'est important
parce que tu vas bénéficier de plein de trucs gratuits, c'est-à-dire qu'en gros,
tu vas profiter de l'outillage, qui sait faire le lien entre les types, etc.
Ça peut être des richards, des intelligents, des riders, des trucs comme ça, tu vas pouvoir
aller beaucoup, beaucoup plus vite pour ton refactoring, pour tes déplacements, tu
peux faire des vrais études d'impact facilement, beaucoup plus simplement que si tu avais
déjà tout découpé.
Donc quand bien même tu voudrais le découper, je pense que c'est une étape intermédiaire
qui est pour moi indispensable, vraiment tu refactores et tu modules un risque d'amor
dans le monolithe, si tu découpes trop tôt, tu fais une optimisation locale et tu vas
tomber en de l'aéros.
C'est un peu le retour d'expérience que tout le monde fait.
Et donc du coup toi, ce que tu dis, c'est que dans ta motivation, parce qu'il y a plusieurs
raisons de plusieurs types de motivations à découper un monolithe, parce que finalement,
tant que tout va bien, t'as pas tellement besoin de changer, c'est quand tu sens que
ça commence à coincer, vous, c'était sur la gestion de la réalise.
Donc j'imagine, ça avait du mal à suivre le flux de délivrer et vous étiez en galère,
parfois pour faire suivre, en termes de structuration de code.
Tu veux absolument t'assurer que toutes les équipes ne vont pas se retrouver bloquées
après un bottleneck, tu imagines que tu as un point central, tu as une seule fontaine
à haut pour tous les meubles, avec à chaque fois que tu veux boire un verre ou prendre
un boin ou faire la vaisselle, il faut que tu ailles faire la queue, en fait c'est un
peu ça, mais en termes de code baisse, c'est-à-dire que si tu as un ou deux éléments, clés,
des commons ou des trucs un peu communs, dès que tu veux faire y factorer, dès que
tu vas rajouter des choses, les uns et les autres peuvent se marcher dessus, donc là,
tu paras des conflits, des problèmes de merges, en gros l'idée c'est déjà avant qu'on
découpe et qu'on se pose la question, est-ce que ça vaut le coup de découper ou pas,
déjà si chaque équipe pouvait travailler sur ces modules à elle, être autonome là-dessus
et que le couplage avec les autres soit vraiment fléché, tu vois, un peu comme dans l'archi
hexagonal, tu as des ports, des interfaces qui sont ce que tu as envie d'exposer publiquement,
tout le reste après c'est pas ta sauce, c'est pas aux autres de savoir comment tu veux modéliser
ton domaine etc. Donc nous on serait partis vraiment par ce qu'on appelle « bundée de contexte »,
il y a des endroits où les gens partagent le même modèle et où un modèle peut être cohérent
sans se confronter, sans se mélanger avec les modèles des autres, par exemple faire en sorte
que si tu travailles sur un module de marketing et tu vois un problème de fidélité pour
un truc dans l'hôtellerie, tu ne vas pas te voir perturber à chaque fois quelqu'un de
l'accontar change un truc, tu n'as pas envie d'être perturbé dans ta côte baisse, dans
tes DTO, dans tes trucs, donc en fait c'est vraiment de baliser déjà à l'intérieur
de l'emmub pour que chacun ait son étage et que chacun puisse être autonome et mettre
en prod quand tu le revis sans demander à tout le monde à chaque fois tout le monde
est d'accord ou pas ?
Donc ce que je comprends c'est que le monolithe tu le rends, tu commences par bien le rangé,
en tout cas c'est ce que, tu imagines c'est ce que vous avez fait, tu vous avez commencé
par bien le rangé étage par étage comme il faut et après est-ce qu'il y en a que
vous avez, vous êtes allé jusqu'à dire bon ben là maintenant ok cet étage là on le
sort et on en fait un service à part entière, est-ce que ça est arrivé et qu'est-ce qui
a motivé cette transition là ?
Alors ce qui a motivé cette transition là c'était pour cette équipe là c'est une
équipe qui est en bout de chaine, en bout de feuilles tu sais donc elle a besoin de
consommer les infos des autres pour fournir des, on appelle ça des custom dashboard,
tu vois tout un tas d'outils qui permettent à nos clients d'avoir une vision synthétique
de leur trésorerie et d'éventuellement de pouvoir l'exposer à d'autres gens pour
aller voir son banquier, pour aller montrer à quel point tu gères bien ta structure et
pour demander des prêts etc et en fait eux ils sont en bout de chaine ce qui fait que
ce qu'ils produisent c'est vraiment que le end user qui les consomme, il n'y a pas vraiment
d'autres API ou tu vois d'autres contextes qui vont aller consommer ce qu'ils produisent donc
deux factos eux ils disent ben on a moyen d'être autonomes avant les autres et comme on aimerait
bien pouvoir réaliser plusieurs fois par jour et qu'aujourd'hui dans le monolithe tout un tas de
raisons on réalise encore une fois toutes les deux semaines mais on est en train de migrer pour
ils est toutes les semaines avant de pouvoir faire du compte des deliveries qui va être notre
objectif on est le 16 septembre donc on est vraiment en train de bosser dessus ben eux ils
sont dit ben tiens nous on peut se détacher un peu plus tôt et parce que ça a du sens aussi et
parce que voilà donc eux ils sont extraits avant les autres parce que c'était pertinent et
excelé rapportent vraiment le plus valu en termes d'autonomie, de réalisme, management etc.
Et quand tu gères la comparte alors parce que du coup quand tu as des comme ça des équipes
qui vont à des des vitesses et des cycles très différents comment tu gères les évolutions par
exemple je sais pas si cette équipe là la dashboard s'appuie sur des API qui changent
alors remarque c'est dans le bon sens parce que eux ils sont capables de s'adapter très vite
et consommer, ça aurait été plus gênant que ce soit dans l'autre sens la différence de facteurs
de réglige mais du coup comment tu as sûr comment il s'assure que les API qui consomment
reste compatible avec leur outil ? Bon ils sont en train de réfléchir à des contract tests par
réfléchir à les faire aussi des contract tests ce sont des tests d'intégration tu sais entre toi et
un système extérieur enfin qui dans le sujet à l'étude c'est un point d'intégration donc par
exemple si tu fais l'architecture exagonale pareil c'est sur un adaptateur qui va appeler
une autre API un autre service pour faire des trucs que toi tu utilises en gros tu vas tester
cet adaptateur là et tu vas sur un ensemble de disquesques qui sont pertinents pour toi parce
que ça se trouve le partenaire ou celui qui te fournit la API donc tu as besoin bah il peut changer
des trucs voir il peut même changer des trucs cassants du moment que tu n'utilises pas ces routes
là tu les consommes pas tu ne vas pas être impacté donc le contact test c'est vraiment
cassant mes usages de ce point d'intégration de cette dépendance extérieure et du coup je vais
tester que ils n'ont pas cassé un truc à partir du moment où nos amis en face vont faire
un breaking change dans leur API un breaking change qui va m'impacter mon contract test il va
échouer et donc en fait alors en général les contract tests comme ce sont des tests d'intégration
ça prend un peu plus de temps certains tests d'acceptation test et tout tu peux même te
permettre de les faire tourner en Adley parce que à moins d'avoir des partenaires qui font du
continuous delivery qui peuvent changer plusieurs fois par jour ou dans ce cas tu l'exécuterais
plusieurs fois par jour en général tu test contre leur environnement de staging ou de dev
ton contact test là et on a été dit c'est suffisant pour se dire ah bah les salauds ils
auraient pu nous appeler pour les actes en faire breaking change mais on vient de s'en apercevoir
cette nuit donc on les contact on les appelle on se met d'accord ou alors on décide ou alors on
peut pas les appeler parce que par exemple c'est google que google ils savent pas qu'on existe
et donc on va pas les déranger on va s'adapter et voilà donc ces contract tests là pour moi
il tourne par exemple dans les listes et c'est le moyen voilà le plus le plus utile à mon sens
pour t'acheter moi ça me si tu veux dans ma dans ma réflexion que j'avais par rapport à ça ça
ça ce que tu vois que me paraissait la base et j'imaginais ensuite qu'il pouvait y avoir
tout un suivi de version et de suivi de la compatibilité et je me disais c'est je voyais ça
comme quelque chose d'un petit petit anesque et quelque part ça me rassure ce que tu ce que
tu me dis ou finalement bah ce niveau que je me suis suffit en fait suffit pour se rassurer et
quand tu es capable de réagir vite bah du coup c'est cool tu ne fasses pas grave au pire le
service est un peu cassé et tu répars vite quoi c'est là où la boîte au tit du domaine de vénizane
est aussi intéressant tu as vu que s'appelle anticorption layer qui est un moyen de ton côté
de te protéger c'est à dire que si tu veux pas te dépendre trop de quelqu'un d'autre tu vas
essayer de pas utiliser son modèle à lui c'est d t o c'est d attenceur object c'est modèle à lui tu
vas tu vas essayer de pas les les fourrer partout dans ton code tu vas essayer d'avoir une petite
membrane à la périphérie ton système qui est le seul endroit où tu vas utiliser leur modèle à eux
tu vas l'adapter dans ton modèle à toi ce qui fait que quand eux ils font un breaking change tu
vas péter que dans cette petite membrane tu vas péter juste le code de l'anticorption
ailleurs tu vas pas avoir à refactorer tout ton code par ailleurs voilà et donc c'est les petites
trucs d'hygiène à voir mais quand tu fais ça en fait s'adapter à un breaking change ça peut être
rapide j'avoue que pendant longtemps je percevez une forme de duplication dans le dans tout ce
passage du monde extérieur vers vers le domaine je je vous ai j'avais cette perception un petit
peu parfois qu'il y avait une forme de duplication et plus j'avance et plus je me dis ben alors
peut-être mais c'est c'est au bénéficier avec des ça vient avec des bénéfices comme ce que tu viens
d'évoquer qui valent quand même le coup parce que par contre le jour où tu te le manges dans les
dents un truc comme ça un breaking change qui a un impact sur tout ta code base tu pleures en
fait je sais que je me rappelle tu pleures pendant des bonnes rappel quand je travaillais dans une
grande banque d'investissement à l'époque on avait un un hibri d'un milieu de l'où ont des messages
s'appelait type courant des vaux qui faisait du multicast qui permettait de faire du pub sub des
coups plein de trucs génial mais le truc était un peu vieux et on avait des problèmes d'infra avec
donc on a voulu s'en débarrasser et un moment donné on a demandé à chaque équipe est-ce que tu
peux me dire combien de temps ça prend pour te débarrasser de ce truc et le remplacer par autre
chose en fait il ya une application les pauvres le couplage avec type courant des vaux il y avait
des types rv messages des structures soit les dto qu'on recevait par la réseau qui était propagée
partout dans leur logique métier donc déjà il y en avait partout et ça c'est juste le premier
effet qui se coule le deuxième effet qui se coule c'est que tout le modèle de ce trading de
leur application était basé sur les prémices du modèle de ce trading de la libre type co qui
recevait les messages qui de notifier des callbacks qui machin ce tarése qui fait qu'en fait pour
sortir de la technologie type courant des vaux pour ce tout cas il fallait tourer c'est le le seul
cas mais ça il m'a vraiment marqué et là je me suis dit ouais les ports adapteurs là c'est quand
même si je me suis dit c'est quand même super puissant quand même pas dégueulé et du coup sur
ce sur ce monolithe qu'est ce que tu retire de cette expérience là c'est quoi les bonnes
pratiques que tu que tu conseillerais de mettre en place au delà de la démarche qu'on explique
alors bon on a dit qu'on modulé les aides à bord on qu'est très bien après moi j'irai plusieurs
étapes c'est d'abord savoir où on veut aller déjà après c'est s'organiser après c'est
naviguer et se repérer dans tous nos changements il ya toute une phase de qui peut prendre des mois
et des mois et y a assez que zé la suite alors si je reprends premier truc genre savoir où est
ce qu'on veut aller là pour moi il faut que tu t'alignes ton code sur le métier toutes celles et
ceux qu'on voulait découper fin des microservice orienté tec et tout ils sont ils sont mordus les
doigts donc vraiment il faut que l'alignement du code soit avec le métier et donc là il faut que
tu identifie tes domaines tu vois chez nous le agica puis c'est le suivi et puis le tâche de la
trésorerie d'une entreprise ontoréale ça c'est un domaine où il a payé ses fournisseurs c'est un
autre produit c'est un autre domaine où se faire payer par ses clients pareil c'est un autre domaine
ça une fois que tu as identifié tes domaines bon là c'est un peu trivial pour c'est quoi le problème
que tu résoudes bah en fait il ya pour un domaine particulier tu vas vouloir identifier tous tes
autres sous-domaine et en fait derrière un sous-domaine on va mapper ce qu'on appelle un contexte
délimité donc par exemple pour le le domaine piloter cette trésorerie tu vas voir comme sous
domaine l'intégration des flux bancaires l'intégration des flux comptables la catégorisation automatique
des encasements des décaissements tu vas avoir le suivi de trésor automatique pour une entité ou une
entreprise après je peux dire pour des magasins pour des filiales etc tu vas avoir tout un aspect
prévisionnel de trésorerie c'est le futur enfin bref je vais pas te lister tout mais en gros tu
vas avoir des sous-domaines et ce sont ces sous-domaines là qu'on va considérer comme
autolome et qu'on va pouvoir un peu packaging dans des modules et dans des alors si tu aimes bien
l'architecture dans des hexagones que tu vas moi j'aime bien une architecture qui s'appelle la
ruche d'hive où tu vas avoir plein d'exagones à l'intérieur de ton monolithe et qui seront
prêt à être détaché en l'occurrence quand ils sont dans le monolithe tout est hébergé dans le même
processus et du coup les appels ces appels de méthode in proc et puis dès que tu veux les sortir
tu vas rajouter les adaptateurs qui vont bien pour faire des appels HTTP des appels rabite et
que tu ouvres ce que tu veux mais mais voilà c'est le même code en fait le code métier va pas
bouger c'est juste la façon de l'instant ci donc en gros premier truc c'est identifier alors ça
paraît évident pour le domaine pour les sous-domaines c'est un peu moins évident et c'est là où les
yeux de storming les discussions avec le métier etc etc ça va être pratique quoi tu fais des
tu fais à la fin tu arrives avec un truc on appelle contexte map qui est une carte des contextes c'est
quels sont tous les sous-domaines et en gros c'est quoi les tu que tu veux protéger ce qui est
intéressant c'est de se dire c'est comme des alvéoles tu vois c'est comme des bulles dans
lesquelles à l'intérieur le modèle il doit être cohérent consistant mais tu vas éviter que le
modèle du notre bulle vienne te percuter vienne se se se remêler avec avec ton modèle tu vas être
autonome tu veux que chaque bulle chaque hexagone et son propre modèle quand bien même tu auras
des noms en commun finalement les usages font que c'est peut-être pas les mêmes structures de données
c'est peut-être pas le même des sur ça c'est le le premier truc et ça encore une fois il faut le
faire avec le métier c'est pas un truc que tu peux commencer ici tout seul côté texte et si
tu as un peu peur et tout et tu vas avoir un peu d'avance mais franchement c'est des discussions
qui doivent se faire avec le métier c'est de l'architecture fonctionnelle donc ça c'est le
premier truc c'est savoir où on volait c'est quels sont les frontières mais tu vois les zones les
modules qu'on veut faire émerger à l'intérieur après mais faut s'organiser comme on attaque le
monolithe alors chez nous c'est des guildes on a 20% de temps pour des sujets un peu tech et on
a sanctuérisé ça récemment les lundis mardi entre on intersprint pour travailler sur les guilds
pour savoir que n'importe quelle équipe enfin n'importe quelle personne n'importe quel équipe
peut travailler sur le sujet de son choix et donc dans ce cas là bah nous on a une guilde qui
est split de monolithe ou modularisé de monolithe donc t'as des gens qui travaillent comme ça
régulièrement sur ce sujet là et c'est l'occasion de se mettre d'accord sur les fondamentaux est-ce
qu'on fait de l'architecture galal ou pas est-ce qu'on fait la ruche ou pas si on fait de l'architecture
comme on branche les modèles contexte quand ils sont une proche c'est quoi les questions de design
bref donc s'organiser et se mettre d'accord sur les fondamentaux ensuite le troisième point c'est
de naviguer et se repérer dans nos changements alors là moi j'ai des c'est là où on fait de la
living dock ici on a des fondus de living dock guillaume bastien christophe mickie avec léman et
pierre qui sont quand on a fait un refactoring christmas donc une période long où on a pu
travailler sur des sujets techniques sans faire de nouvelles features cet arabe on a pris presque
un mois pour faire ça ils nous ont sorti un ensemble d'outils qui sont géniaux qui permettent de
structurer à en générer des diagrammes dans des margantes dans de la doc etc ce qui fait qu'à
tout moment dès qu'on build notre monolithe on sait qu'elles sont les modules on sait qu'elles
sont les dépendances quels événements sont consommés ou publiés quels épia sont-elles appelées par
les uns les autres donc en fait on a une cartographie en live tu vois on n'a pas besoin de se faire
à se refaire des dessins etc en tout cas en torrelle et donc là ça permet de savoir est-ce qu'on a
des couplages qu'on n'avait pas imaginé donc on veut se débarrasser etc etc et est-ce que ça
voilà ça correspond est-ce que la carte et le territoire sont lignés par rapport à ce qu'on veut
donc la living dock pour moi c'est pour découper un monolithe c'est un outil qui est vraiment
intéressant là on génère des diagrammes avec du mermed pour essayer ça dans les pages markdown
et on a une sorte de mini-site qui est générée à chaque fois qu'on build notre monolithe et enfin
donc ça c'était la partie naviguer se repérer dans nos changements c'est comme ça qu'on sait
ce qui nous reste à faire quand on a bien séparé ou pas les concepts et après c'est sécurisé la
suite et pour ça pour moi il y a les contractesses dont j'étais parlé donc c'est quel type de
dépendance on s'autorise à avoir entre le module de marketing et le module de contente par exemple
quel contrat et des tests d'architecture par exemple c'est de se dire je veux pas que les
packages du domaine référence des packages techniques je veux que chaque exposition du modèle
de lecture quand tu fais de sécurité ce n'est pas une seule bout de contexte par exemple je veux
tu vois que l'honor ship et ça tu arrives à l'inforce avec du code des espèces de linters
ou des analyseurs de code ou assez des tests comme des tests unitaires mais des tests d'architecture
c'est des tests sur lesquels on peut introspecter le code et avoir la liste de tous les modules
avoir leur nom et on tu vois on on forcer ou détecter des anomalies tu vois par exemple qu'un
projet du génial un truc qu'on a mis au début c'était je veux pas qu'un projet du domaine d'un
monnaie de contexte dépend directement d'un projet domaine d'un autre monnaie de contexte
parce qu'on veut toujours passer par un adaptateur de couche d'infrains donc voilà c'est le genre
de truc que tu peux écrire en 5 ou 6 lignes de code et qui va te permettre de garantir que
ton architecture tes principes d'architecture tes adhères tout ce que tu as décidé collectivement
c'est à dire se pour renforcer et pas casser dès qu'il y a quelqu'un qui démarque surtout quand
tu recrutes et que tu rembordes voilà bah c'est c'est indispensable éviter que tu vide que tu
remplis la baignoire d'un côté et que tu la vide de l'autre quoi enfin tu vois que
donc en gros pour moi c'est ça c'est un savoir où on veut aller donc bien connaître le métier
le domaine et les territoires deux c'est s'organiser comme on s'attaque à ça 3 c'est naviguer donc
la living doc etc c'est la carte qui permet d'avancer et 4 c'est sécurisé avec des dispositifs un
peu des arnais tu vois d'architecture des arnais de test avec les contrats que tu as
été motivé parce que là on est hyper motivé on a des que des gens super motivés ici là pour je
crois c'est une des guils plus de succès du coup on arrive à avancer finalement relativement vite
est ce que tu as des exemples de moments où où tu cahes un peu le fruit t'es en travail parce que
le le retour d'explan ce que j'ai moi personnellement sur ces sujets là c'est que c'est un travail un
petit peu long parfois un peu facile d'eux où il faut mettre beaucoup d'énergie qui a une progression
qui est faible au début puis à un moment donné il ya tous les alignements qui se mettent en place
d'un coup il ya un progrès énorme qui vient d'arriver tu vois ce que c'est pas exponentiel mais c'est
un peu en marge d'escalier c'est-à-dire que tu as un travail de patience où tu nettoies tu nettoies
tu nettoies et puis d'un coup clac il ya tous les verrouilles qui se déoverrouille et qui s'alignent
puis pouf tu as un un saut soudain de progression est-ce que c'est un peu ce sentiment que tu as par
moment oui et c'est quoi les des pas comment tu le matérialise ces choses là alors pour bah oui
c'est vrai c'est tout à fait exact je pense que tu vois tous les ce qui est le vignes doc et tout
si on n'avait pas eu ce temps un peu investi à un moment donné pour préparer le tiage
ben ça nous aurait ralenti il y a peut-être ce qu'on va faire la main tout alors on commence à se
matérialiser mais par exemple l'équipe custom d'admort qui peut commencer à se découper et à
prendre son autonomie et à vie sa meilleure vie parce qu'elle est plus tributaire des cycles de
release du monolithe par exemple ça c'est un premier un premier cas qui fait que bah ils sont
ils sont contents et puis un autre cas c'est le l'alignement donc nous on a une architecture
chance monolithe qui est sécuraise donc il ya les modèles de lecture et modèle d'écriture
qui sont séparés c'était de se dire bah comment on comment on se découpe ce modèle de lecture
il y avait ici ou là dans le dans tout legacy des petits défauts il y a eu coup il y avait le
modèle de lecture dont l'honorship était pas clair et donc ce modèle c'est ses exposition
tu vois de couéries et c'est un mode de lecture on savait pas trop où les foutre est-ce que ça
parfois ça mélangait des préoccupations d'un bout de contexte a d'un bout de contexte b ça c'était
parce qu'en fait notre monolithe il faisait aussi back end for fontaine c'est à dire que
t'as des écrans où tu veux afficher des choses qui appartiennent à plusieurs bout de contexte et
donc en gros pour y arriver ben derrière cet écran il y avait une grosse couérie pour cet écran et
se trouve que cette couée elle elle venait prendre des infos à droite prendre des infos à gauche
tu vois dans différentes alvéoles différentes exagones pour le pour le faire mais du coup
maintenant qu'on a bien découpé ces modèles de lecture on peut non seulement mieux découpler
et mieux lire et comprendre à qui à partir quoi en termes d'honorship de code tu vois par rapport
à des équipes mais en plus ça nous permet aussi d'extraire des bases de données aujourd'hui on
avait une énorme base de données est-ce qu'elle serveur qui faisait le qui servait pour tout
le monde ben là on peut commencer à découper chaque modèle contexte et même si ça sera dans
le même process pour commencer parce que c'est un modélite modulaire ce modélite modulaire
chacune de ces alvéoles chacune de ces exagones va pouvoir aller taper sur sa base de données à lui et
donc bah en fait c'est pour éviter de la cible tu as bien aligné ton code et tout et puis tu
arrive une situation où t'as le chip il y a même là sur internet où t'as l'étoile noire tu sais de
Star Wars puis t'as deux tif fighters là où il se fait être à côté il a écrit ceci et la
représentation de deux microservices et de leur base de données en fait et donc les toiles noires
énormes qui prend toute la place c'est la base de données puis à deux microservices en fait en vrai
ils sont pas faillissons fortement couplés quoi les toiles noires disparaient les deux ex fighters
là dans l'espace ils sont un peu tout seul donc du coup ça te permet de préparer la suite c'est
à dire de bien découper également aussi en termes de modèle de base de données etc. Donc ça c'est
des steps tu vois quand tu arrives à le faire tu as assez cool on avance on peut déployer de manière
indépendante on évite d'avoir des database asmit de l'oer qui a un antipaterne aussi que tu quand
tout le monde utilise la même base de données c'est facile d'aller tirer des câbles tu vois
n'importe où d'aller lire n'importe quoi. Donc voilà ça a plus de la doc. Bon après je me sens
obligé de rectifier les ex fighters c'était ceux de la rebellion. Ah ouais je me trompe.
En fait depuis tout à l'heure je reste bloqué la suite donc il faut que je me dise que ça peut
passer à chose. Donc voilà. C'est mon passé de reliste en Star Wars qui vous fait pas. Ouais ok
Ecoute hyper riche. Quelles leçons tu tires de tout ça ? Les leçons je ne sais pas moi c'est du
plaisir surtout en fait c'est du plaisir ça m'est arrivé par le passé. Je vais reposer la
est-ce que tu vois si tu avais un conseil allez plutôt si tu avais un conseil à donner à quelqu'un
pour s'embarquer là dedans. Alors le premier ça serait découpe pas trop tôt introduit pas du
réseau tu sais pas encore mais tu vas ouvrir une boîte que tu vas avoir du mal à gérer donc
à refermer etc donc refactor tout ça dans la même solution dans le même projet dans le même
truc dans le même modélite. On ne découpe pas trop tôt découpe vraiment à la toute fin et
encore quand t'as compris ce que ça va t'apporter. Le premier truc deuxième truc c'est de l'alien.
Parce qu'on a compris si tu arrives jusque là si ça se trouve tu n'as même pas besoin d'aller
jusqu'à la phase du réseau. Ouais exactement. Exactement. Tu vois il y a des par exemple le
Dr. Lib bon alors c'est The Boring architecture etc mais c'est un énorme monolithe avec une seule
base de données. Ils sont 400 je crois d'oeuvres dessus maintenant et ils arrivent à réuniser plusieurs
fois par jour. Alors il y a des contraintes. Attention il y a plein de trucs et tout. Je suis pas
en train de dire qu'on fasse tout comme Dr. Lib mais tu vois il y a des gens c'est une question
quand c'est posé sur le compte des délivrées puisque c'est un autre guide et c'est un autre
sujet qu'on travaille beaucoup chez nous. Est-ce qu'on a besoin de découper le monolithe pour faire
des continuités de délivrie oui ou non ? La réponse est non je pense qu'on peut avec un
monolithe modulaire et quelques bonnes règles on peut déjà aller faire du continuité de
délivrie et après si tu vas aller plus loin tu peux aller en découpant. Donc moi je dirais tu
modularises dans le même dans le même monolithe déjà et après il faut surtout savoir aligner ton
code avec le domaine avec le métier donc il faut bien comprendre le métier il faut bien comprendre
les frontières où tu veux les mettre avant de t'attaquer au truc et puis troisième truc ça
serait de l'archi hexagonale pour moi c'est un truc assez pratique pour commencer comme des
playsolders tu vas en forcer l'encapsulation de ton code on l'enferment dans des mini citadelles
pour éviter que tes modules et tes modèles ne fuient et forcément la passer par tes
ponts le ville à tes ports et tes adaptateurs les seuls endroits où tu autorises les gens à venir
te poser des questions ou à te dire des choses. Merci merci pour tout ça. Est ce que tu as envie de
rajouter quelque chose sur cette thématique ? Ecoute non il n'y a rien qui me vient comme ça.
C'est quand même bien moi le plaisir chez Agica c'est que c'est des gens qui connaissent déjà le domaine
des aides qui s'intéressent au domaine et qui ont envie de découper par rapport au domaine et donc
avoir des copains et des copines de jeu avec qui tu vas pouvoir jouer ce jeu là plus avoir une bonne
relation avec le produit c'est quand même un énorme pas c'est à dire que moi j'ai un préroquis
intéressant c'est que j'ai tout ça déjà chez Agica donc j'ai pas à les vendre le chantier le
sponsoring c'est à nous notre objectif là c'est d'aligner notre code et notre archi avec le domaine
toujours par un bon time to market et tout c'est le tout c'est Jean-Baptiste Dussault qui disait ça
mais c'est Arnaud le maire je crois dans un des podcasts j'ai réentendu la phrase de Jean-Baptiste
aussi qu'il citait qu'il dit en gros la qualité d'aujourd'hui c'est la productivité de demain
il y a un truc comme ça et j'aime bien ce que là voilà en ayant notre code bien aligné par rapport
au métier on se facilite la vie on est vachement plus de tout market et plus efficace correctif
merci Thomas pour tout ça merci pour son tour d'expérience je t'en prie si les auditeurs veulent
te suivre ils peuvent te suivre où en savoir plus où alors à part sur sur twitter c'est
jusqu'à ce que je devine mon blaze un tp1 si on tpi 2 r a yn et je suis pas trop souvent sur l'inkine
passé je pense mais pour un vieux c'est une énigme mais mais voilà c'est à peu près tout pour les
questions pour les épouages cap mais on mettra les liens ou qu'est ce que tu veux donner comme
bien pour moi il y a une page carrière je suis un étudiant comme on mettra le lien si tu veux bien
enfin du casse merci tomas d'être venu aujourd'hui merci à toi mais non quand t'as touché au
réditeur bah j'espère que t'as kiffé cet épisode encore une pierre de plus dans le sens de la
modularisation des choses je t'invite à venir découvrir le live qu'on a fait avec poline carot
de chez de chez jk aussi sur cette idée de d'architecture hexagonale où on a un live où
elle prenne un morceau de code un peu craquera et elles en font bah elle passe sur ce type de
design je t'invite vraiment à venir découvrir la chaîne youtube sur bah tu t'as parti dans
développeur dans youtube en fait et tu vas avoir ce live il est assez pédagogique il est vraiment
bien fait et je t'invite venir à venir découvrir cette ressource je te remercie et je te dis à bientôt