Hey, everyone, welcome to the Unhandled Exceptions podcast. I'm Dan Clark and this is episode
number 59. Now, I'm sure a lot of developers have heard of terms like techs, agonal architecture,
ports et adapters, union architecture, clean architecture, et so on, mais je pense que les
plus que je ne comprends pas ce que ça veut dire et ce sont les différences entre eux.
Et si c'est vous, j'espère que cet épisode peut vous aider. Parce que aujourd'hui,
je suis venu par Valentina Soupach à parler de l'architecture agonale et de
essayer de démystifier ce que c'est et comment il compare à d'autres types d'architecture que
je m'ai mentionnée. Valentina, bienvenue à la show.
Merci beaucoup, je suis vraiment excité pour cette session aujourd'hui. Merci pour
l'invitation. Oh, bienvenue. Je suis en train de voir comment on fait ceci
sans des diagrams et des choses. Ça devrait être intéressant.
Donc, pouvez-vous vous introduire à l'écart de l'écart et vous dire un peu de ce que vous faites?
Oui, je suis un coach technique au OptiVem et j'aide les compagnons et les équipes à
augmenter le niveau de qualité de software dans leurs pratiques de développement
afin de speed up la delivery et de réduire les bugs et d'augmenter le nombre d'équipes de développement.
Et le moyen que je fais est typiquement d'introduire l'architecture agonale, la
architecture clean et aussi les pratiques de développement test. Et j'aide les équipes
à introduire ceci sur leurs projets réels. Donc, ce n'est pas des pratiques simulées ou
des projets catholiques, mais des projets de production réel, pour qu'ils puissent voir
que ce n'est pas des pratiques théoriques, mais que, oui, ceci fait que les résultats réels
sont en actualité des projets de production. Ça ressemble vraiment à ça. Je crois que vous avez
vu beaucoup de différents codes basés sur les niveaux de qualité, si vous vous
vous vous interviendrez. Ça ressemble à un rôle intéressant.
Oui, je vois des projets différents dans les langues différentes, dans les pays différents,
et sur les aspects surprises, ce que j'ai vu des similaires dans la base de la base de la base.
Oui, c'est un point commun que je vois, parce que beaucoup de codes basés sont assez
âgés, peut-être que ça m'attrape par le long terme, mais beaucoup de codes basés ont
eu beaucoup de différents développeurs, peut-être des contractes et tout pour un temps où il y a
beaucoup de différents patterns de design qui ont été élevés, et pas de consistance.
Mais c'est très commun. Oui, exactement. Comme vous l'avez observé,
beaucoup de les équipes ont eu de la même manière que les développeurs et les pratiques différentes,
parfois des exceptions et des logins, et même ces choses pourraient être faites dans
plusieurs différentes manières, ou la équipe pourrait aussi avoir été travaillée dans les silos,
et si vous regardez à une partie du code et à une autre, vous pouvez dire que c'était fait
par des gens différents. C'est un challenge très commun que j'ai observé, et un autre challenge
commun que j'ai aussi observé est de avoir des classes grandes avec le logic de business et l'infrastructure
tous bundlés ensemble, à l'extérieur, que ça devient vraiment difficile de lire, difficile de comprendre,
incroyable, et quand un nouveau histoire de user bug fixe s'entend, c'est vraiment, vraiment
difficile de savoir comment implementer correctement.
Oui, définitivement. Ce sont des classes grandes avec 50 différents statements de si,
et ils sont tous messés, et puis il y a des fours-reaches à l'intérieur, et puis...
Exactement.
Vous devez faire un nouveau feature, donc vous ajoutez un autre statement de si, et ça se fait
plus ou plus, c'est horrible, horrible, horrible.
Mais, avant de parler de texte, de l'architecture, juste un petit souvenir pour les listeners,
que ce podcast a de sa propre communauté de discote, si vous vous passez au site
UnhandledExceptionPodcast.com, vous verrez un gros discote là-bas, et je
aussi ai une nouvelle newsletter où je vous couvre des trucs sur les releases de podcast,
des épisodes d'opérations, et je parle de tout ce que je fais aussi, comme le
YouTube-channel.net d'Oxford User Group, et aussi je mets un bunch de picks de
nouveaux items de la dernière année, et un pick de détail de détail, donc il y a un lien
sur le site, aussi.
Et plus qu'il y a de la compagnie, ce podcast est sponsorisé par Everstack,
qui est mon propre company, qui permet de faire des services de développement de software
et de la consultation pour plus d'informations visite at Everstack.com.
OK, hexagonal architecture, donc normalement quand je regarde
dans cette ou une architecture, ou une architecture clean, je vois des
grands diagrams de la circonscription, en essayant de ne pas expliquer.
Donc, évidemment, c'est un podcast qui n'est pas d'audio,
donc on n'a pas de l'avantage, donc on peut faire notre best-though.
Maintenant, je pense qu'on peut commencer par expliquer l'architecture hexagonale,
ou on peut commencer par expliquer les problèmes que c'est de la solution.
Donc, je pense que vous êtes l'expert de expliquer cette chose.
Où est le meilleur endroit à commencer ?
Je dirais commencer par la réalité de la currentité des projets.
Comment sont-ils structurés, identifiant le problème et ensuite introduire
l'architecture hexagonale, simplement parce que c'est peut-être un nouveau terme pour nos listeners.
Ça me semble bien.
Qu'est-ce que le plus commun de l'architecture ?
Quelles sont les gens qui ont essayé de utiliser avant l'architecture hexagonale ?
Oui, je dirais que le plus commun de l'architecture est la architecture libre,
ou quelqu'un qui s'appelle la structure libre, ou l'application crade,
où quelqu'un implemente les contrôles,
on dirait les contrôles rest-api, ou les contrôles MVC.
Je vais donc continuer avec les contrôles rest-api.
Et ensuite, avoir des classes de service,
et c'est là où ils impliquent le logic de business.
Et enfin, avoir des entités qui sont relatives à la base de la database.
Donc, juste pour donner un exemple,
avec .NET, quelqu'un peut utiliser ASP.NET pour faire des contrôles rest-api.
Pour exemple, avoir un contrôle de l'ordre d'ordre,
qui a des méthodes HTTP pour créer un nouveau ordre,
donc, post-ordre, put-ordre,
délit-ordre, peut-être pour la cancellation, etc.
Et ensuite, le contrôle rest-api s'appelle la classe de service,
donc on pourrait avoir un classe de service de service de l'ordre,
et sa interface correspondante,
sa interface qui a des méthodes, pour exemple,
créer l'ordre, approver l'ordre, cancel l'ordre,
et dans cette classe de service,
c'est là où nous avons le logic de business.
Donc, pour exemple, il y aurait un logic de business
quand on fait l'ordre d'approvision,
et on va voir que, en première, la check-in existe,
checker que sa status est en drap,
puis changer sa status pour approver,
puis sauver dans le database, etc.
Donc, ce genre de logic de business
serait dans la classe de service,
et la classe de service
s'appelle certaines entités, comme l'ordre,
et il s'appelle aussi, on dirait, le contexte d'enver de Db,
puis on a le contexte d'enver de Db,
on a le set d'enver de Db avec les ordres,
pour communiquer avec le database,
en utilisant le framework d'entité.
Donc, je vois cela comme, on dirait,
un point de départ pour le projet.
Maintenant, pour avoir la prochaine partie de la question
que vous avez évoquée,
c'est ce que sont les problèmes avec cela.
Initialement, quand on commence un projet
qui est la plus commune structure,
personne ne voit aucun problème avec cela.
En fait, c'est le plus rapide de commencer un projet,
mais, quand le temps passe,
les problèmes commencent à s'émerger
plus visiblement dans cette classe de service.
Donc, la classe de service d'ordre,
qui a initialement été peut-être 10 ou 20 lines,
en plus de 100 lines,
des milliers de lines,
et on termine avec peut-être 50 statements
de l'évaluation, comme vous l'avez mentionné.
Donc, il devient très difficile de lire,
c'est un problème.
Mais le autre problème aussi,
c'est que nous sommes en mixant le logic business
avec toutes ces quies de framework d'entité,
et ça peut être vraiment malade
de se faire avec tous ces quies dans un endroit.
Et le dernier problème qui vient aussi là-bas,
pas seulement de la couple avec l'entité,
mais aussi, imaginez qu'on doit décider
d'autres services micro ou des systèmes de partage,
comme peut-être des ERP ou CRM,
et puis, quelqu'un peut être en train de ouvrir
une connexion de client HTTP
dans la classe de service de la middle,
pas seulement d'une code additionnelle,
mais maintenant, nous sommes en mixant
plusieurs questions de business
logic, qui est mixé avec le database,
qui est mixé avec les calls
pour d'autres services de service.
Donc, tout ça est dans un fil.
Le problème est la mixation de concerns
et la testabilité.
Comment pouvons-nous univerter la logique business
si c'est mixé avec la code database,
si c'est mixé avec le client HTTP,
on ne peut pas univerter la logique business.
Donc, c'est ces deux problèmes
que l'architecture texte
tient à résoudre les concerns de séparation,
l'issue de la logique business et l'infrastructure,
et l'issue de la testabilité associée avec ça.
Oui, et je pense que ça aussi
s'est résoudre l'incombre,
parce que nous avons parlé de l'outgo,
pour le database,
et cela étant très bien couplé.
Mais je pense que si vous mettez
le contrôle de la logique business,
vous êtes bien couplé à ASP.net.
Donc, je pense que c'est l'autre côté
de la coupling aussi.
Exactement.
C'est vrai.
Donc, la coupling que je pense que je l'ai décrochée
pour savoir, c'était juste dans la classe service,
qui était la coupling d'outgo.
Mais il y a aussi une coupling d'incombre,
qui est le cas que certains équipes
n'ont pas de classe service,
qu'ils mettent la code
dans les contrôles rest API directement.
C'est une variante que j'ai vu,
où les contrôles rest API,
qui est essentiellement une présentation,
sont ensuite couplés
à la logique business et tout autre.
Et l'autre variante que j'ai vu
sont les équipes qui ont les contrôles rest API
et les classes de service.
Mais les contrôles rest API
sont aussi en train de faire des logiques business.
Donc, la logique business est
couplée à la logique service
et les contrôles rest API.
Et puis, encore une fois,
c'est aussi un autre variante
de présentation,
d'incombre, essentiellement, de coupling.
Je pense que c'est aussi possible que je vois
que même si vous avez un classe service,
donc vous avez cette séparation,
que peut-être que les gens
vont passer par les mêmes DTOs.
Donc, le web API DTO
que l'on appelle ou l'application de l'application
et passer par la logique service.
Donc, vous avez la coupling là-bas.
Et je pense que c'est comme un balan.
Non?
Vous avez beaucoup de DTOs
et beaucoup de fonctionnalités de mapping?
Ou avez-vous passé la même DTO
par la logique et avez-vous la coupling?
Donc, je vois que les pros et cons
sont vraiment les deux.
Mais la coupling est intéressante.
Oui. Et sur le sujet de la DTO,
c'est une toute conversation en soi-même.
Par exemple,
ce que les meilleurs teams
typiquement ne peuvent même pas faire
est initialement pas avoir d'autres DTOs,
mais en fait,
avoir une entité,
une fréquence d'entités
passée dans les contrôles de l'application.
Donc, j'ai vu ça
comme un point initial
et ensuite les teams
qui ont séparé des DTOs,
mais en utilisant les mêmes DTOs
par les méthodes d'application de l'application,
en fait,
c'est un point de vue
de la question de la dernière question.
Peut-il que les contrôles d'application restent
les mêmes ou les différents DTOs
par rapport aux classes de service
sont lesquelles je vois
deux possible risques
que nous devons avoir à l'avenir
plus tard,
car c'est un certain détail
des options d'implementation.
Oui, ça me rend le sens.

les différents architectures
que je m'ai mentionnés avant,
donc l'une des autres
était les portes et les adapters.
Est-ce correct de dire
qu'elles sont les mêmes ou les portes et les adapters
et l'architecture hexagonale ?
Ça juste signifie la même chose.
Oui,
donc sur l'article de l'article de l'Alister Cockburn,
de ce que je me souviens,
historiquement,
que le premier nom était portes et les adapters,
après,
la même chose était appelée
l'architecture hexagonale
et simplement l'architecture hexagonale
comme un terme
se sont beaucoup plus populaires,
mais toujours les deux termes
continuent à être utilisés interchangablement.
Il y a eu confusion
par rapport au nom de
l'architecture hexagonale
comme le hexagon.
Est-ce qu'il y a une signification
spécifique de prendre un hexagon ?
Et le point est non,
il n'y aurait pas été
d'autre polygon,
il n'y aurait même pas été un cercle
ou d'autre.
C'est inélevé.
La seule partie
qui est inélevé
est
que nous avons quelque chose
pour symboliser notre application,
qui est déjeunée
comme un hexagon
en architecture hexagonale.
Et nous avons l'autre monde.
Oui, c'est un des questions
de ma première question.
Pourquoi est-ce qu'il s'appelle
l'architecture hexagonale ?
Je pense aussi que
je pense que ça s'amuse
dans le fait que
les hexagons sont allés ensemble.
Donc si on a un whole bunch
de hexagons ensemble,
ils peuvent parler
à l'un de l'autre,
mais dans ce
monopole de décapelage, je pense.
Oui, j'aime que tu as
créé ça.
Parce que,
par exemple,
dans le cas de
monolithes modulaires,
quelqu'un peut avoir
la possibilité
d'utiliser l'architecture hexagonale
pour
l'application de l'architecture.
Par exemple, pour cet application restée,
il faut avoir un hexagon,
mais alors que quelqu'un
pourrait éteindre cette idée
dans une version
plus déchirée
pour avoir,
je dirais, plusieurs hexagons
et qu'ils parlent à l'un de l'autre.
Oui, ça fait du sens.
Donc, juste pense
sur ce point de l'adaptation de la portée.
Peut-on définir
ce que l'adaptation de la portée
et ce que ces thèmes
sont ?
Oui.
Donc,
pour le premier, imaginez dans notre tête
que nous avons
notre application,
qui est,
donc, imaginez un hexagon
dans notre tête
et
nous avons cette séparation.
Le hexagon, en itself,
a un bon boundary.
Et si il a un
insides,
ou il a des internes,
et puis il y a l'extérieur.
Le boundary hexagon
a des portes sur le site.
Donc, nous avons
des portes d'arrivée
et nous avons
essentiellement des portes d'arrivée.
Les portes d'arrivée,
elles sont appelées
des portes d'arrivée
et les portes d'arrivée
sont appelées des portes d'arrivée.
Donc, c'est là où,
vous savez,
le côté gauche,
l'arrivée et
le côté droite
sont des portes d'arrivée.
Donc, ces,
je suis juste maintenant pensée
que, pardon,
je dois continuer à utiliser
les mots officiels
sont
portes d'arrivée
et portes d'arrivée,
mais en fait,
les mots intuos de la façon
sont
portes d'arrivée
et portes d'arrivée,
même si
ce n'est pas les officiels.
Donc, je dirais
pour une meilleure compétition
de l'économie,
que peut-être on pourrait continuer
avec la façon informale
de la parole
pour le reste de la podcast.
Oui, je l'ai dit,
ça fait du sens.
L'économie et l'arrivée
sont très intuitives,
donc ça fait du sens.
Oui, oui.
Et pour l'audience,
simplement pour savoir
que je vais répéter
de l'autre côté,
l'arrivée est
les portes d'arrivée
et l'arrivée
est les portes d'arrivée
dans les diagrams officiels.
Donc, juste pour vérifier,
quand on parle avant
des services et
des databases
et des choses d'arrivée
en étant de l'application web,
est-ce que ce que nous parlons
de ces portes?
Oui, oui.
Et maintenant, on va
aller au plus précis de la façon.
Maintenant,
quand on pense
aux portes d'arrivée,
ça veut simplement
que quelqu'un
veut envoyer
certains commandes
sur notre application.
Je dirais que c'est le plus simple
de la façon de penser.
Donc, si quelqu'un
veut dire à notre application,
peut-il créer un ordre?
Est-ce que vous pouvez approcher un ordre?
Est-ce que vous pouvez canceler un ordre?
Donc, si quelqu'un nous dit
que nous sommes recevés
comme un signal d'arrivée,
à ce point,
nous n'avons pas d'idée
qui est envoyé
ces commandes,
essentiellement.
Est-ce que nous sommes envoyés
par l'application restée,
par l'application web,
par l'application console?
Nous n'avons pas de soucis.
Nous allons voir
ce que nous avons ensuite.
Mais tout ce que nous carenons
est que nous exposons
des portes ou des portes
dans notre maison.
Nous pouvons penser de notre application
dans notre maison
et nous pouvons penser de ces
portes à l'incompréhension
comme nous serons
en train de ouvrir une porte
pour que quelqu'un nous parle
de « hey, pouvez-vous s'execuer? »
Ceci.
Alors,
tous ces portes à l'incompréhension
sont sur le côté gauche
de la hexagonale.
Ensuite, sur le côté droite,
nous sommes aussi exposés
des portes, mais pour une
différente cause.
Pour la cause que nous
devons communiquer
avec quelque chose de l'extérieur,
nous devons
appeler quelque chose.
Donc, notre application de l'ordre
devra appeler
un database.
Il devra appeler
quelque chose de l'enquête du fil.
Il devra appeler
quelque ERP,
comme peut-être SAP ERP.
Il devra appeler
quelque CRM,
peut-être, de la force de sales.
Et à ce point,
nous n'avons pas besoin
de savoir
ce que sont les protocoles
et les technologies
derrière ces choses.
Donc, pour exemple,
pour les databases,
nous sommes en train de
mettre sur l'application
qu'on ne careste pas
si c'est un database SQL
ou pas un database SQL.
Nous ne caresterons pas
si l'ERP que nous communiquons
est-ce qu'ils ont un API REST
ou si c'est un service de SOAP
ou si c'est un mechanism de FTP.
Donc, nous ne voulons pas
quitter ces
concerns infrastructuraux.
Et puis,
cela signifie que quand nous modélons
les portes en arrivant,
nous modélons-nous
dans ce que nous voulons
envoyer
dans un de l'absence
Donc, pour exemple,
je pense que je dois communiquer
avec un ERP.
Peut-être, je dois envoyer
mes idées d'ordre
et, pour dire,
le prix d'ordre de l'order.
Et puis, j'ai une interface
pour représenter ce port
qui dit que c'est le date
que je vous envoie
et aussi ce que je suis
expectant de retourner.
Et dans cette interface,
je n'ai pas idée
ce sera l'implementation
qui sera la paix restée
ou SOAP
quand nous communiquons
avec cet ERP.
Et par interface,
on parle d'un interface C-Sharp.
C'est une question vraiment bonne,
interfaces.
Donc, dans l'architecture hexagonale
comme concept,
ils referent
les interfaces
dans le plus conceptuel
irrespective de la langue.
Certaines langues
ont aussi des interfaces
comme C-Sharp.
Il y a aussi
des langues qui ne sont pas interfaces
mais qui ont quelque chose de similaire.
Comme, exemple,
Python ne doit pas avoir des interfaces,
mais il y a des classes abstractes.
Et peut-être qu'il y a aussi
des autres types de langues
qui ne sont pas même interfaces.
Donc, juste de retourner
vers C-Sharp,
spécifiquement,
oui, dans C-Sharp,
quand l'implementation
nous serons utilisant des interfaces.
Le plus facile de dire oui
à des interfaces
est
sur le port de l'outre-de-garde
qui a des imprimations
qui sont utilisées des interfaces.
Sur l'incombre,
vous avez des interfaces,
par exemple,
vous avez un interface
si vous utilisez des services d'application
où vous avez un interface pour le service
et un interface
pour la classe de service.
Mais si vous êtes,
par exemple,
utilisant des interfaces

des types de commande,
dans cette situation,
vous ne vous faites pas
vous avez des interfaces
mais, par exemple,
vous utilisez des interfaces

Donc, dans cette situation,
il y a un peu de
des options en termes de fausse.
Je pense que dans ce cas,
c'est la demande des médias.
Est-ce que la interface est effectivement
en réponse ?
Oui,
dans ce cas,
nous serons passés
à l'interface de l'I-mediat.
Donc,
ce serait l'interface de l'I-diet.
Donc,
c'est à dire
en utilisant l'interface de l'I-diet
ou en utilisant nos services.
Donc, pour les portes de l'outre,
est-ce correct que,
dans le contexte de la classe de service,
que
un port est un interface
et un adaptateur
est une implementation de l'interface ?
Oui.
Donc, ça veut dire
que, on communique avec un ERP
et on pense
qu'il y a une raison
pour laquelle nous avons besoin
de l'ERP
c'est parce que
nous devons les envoyer,
nous devons,
dire,
les mettre en place
notre ordre.
Et la autre raison
pour laquelle nous avons besoin
de l'ERP
est après
d'avoir l'ordre de l'ordre
parce que l'ERP
derrière,
il y a un place de manufacture
ou de production
et
ils ont des employés
et l'ordre
est, on dirait,
un package
puis un tour de l'économie.
Donc, l'ERP connait
l'état actuel.
Donc,
nous défendons
un interface
et il a, on dirait,
deux méthodes.
Par exemple,
envoyer
l'infos où nous envoyons
l'ordre d'ID
et
l'ordre de la prise
parce que c'est ce que l'ERP
veut nous envoyer.
Et nous avons une autre méthode
qui s'appelle
l'ordre d'ordre
et nous passons
l'ordre d'ID.
Donc, c'est l'interface.
Et ensuite, on a une implementation
et on dirait que cette interface
on appelle
l'économie d'économie ou quelque chose.
Et ensuite, on a une implementation,
on dirait qu'on utilise SAP
donc peut-être qu'on appelle
l'économie d'économie d'économie.
Et c'est une classe concrète
et ça implique cette interface
et dans cette implementation
c'est où peut-être que vous avez un client
de l'HTP
qui s'appelle
le SAP REST API
ou le SAP SOAP Service.
Ça me dit et c'est cette implementation
qui est l'adapter à la partie des choses.
Oui, exactement.
Donc, ce SAP Warehouse Gateway
classe est un adapter.
Ah, ça me dit.
Donc, et puis, je pense que
le nom que vous avez donné
l'interface
n'a pas été envoyé
à ce que c'était appelé
et que c'était appelé SAP.
C'était juste comme l'équipe de business
plutôt que le détail de l'implementation.
Exactement.
Donc, la choice de SAP
est visible
comme une technologie
infrastructure
extérieure
concernée.
Et c'est pourquoi le nom
de l'interface
n'est pas donné
le nom de l'économie
que l'on utilise.
Donc, on ne va pas donner
la façon à laquelle on utilise
SAP ou Salesforce
ou quelque chose d'autre.
On n'est pas donné
ce que ça donne.
On n'est pas donné
le protocole.
Donc, quand on appelle
le port de l'outre,
on n'a pas le nom de
HTP,
donc,
restes.
Donc, on n'est pas donné
quelque chose de protocole
ou de mechanism de communication.
Aider.
Ça fait un tout le temps.
Donc, effectivement,
en utilisant le termen de port
et d'adaptes,
conceptuellement,
on pourrait dire
qu'on va avoir
un autre adapteur
qui a fait
quelque chose d'autre.
Il fait le même chose
dans un autre façon
et vous pouvez placer
un adaptateur différent
dans le même port.
Donc, c'est un très
plou con player, je pense.
Exactement.
C'est exactement correct.
Donc, quand on a
le port
d'outre,
il peut avoir
implementation comme
SAP,
d'outre,
qui est un adaptateur possible,
peut-être un Microsoft Dynamics,
d'outre,
implementation.
Donc, si on a
plusieurs vendours,
on peut avoir
plusieurs adapteurs pour ça.
Ou, on peut dire,
imagine,
SAP
en première,
en utilisant un API resté.
Mais ensuite,
ils sont en train de changer
de service de soupe.
Donc, on peut peut-être
avoir
un SAP resté
au gate de l'air
et ensuite, on a
un SAP
service de soupe
au gate de l'air.
Oui, ça fait un sens total.
Alors, pourquoi quelqu'un
qui a eu de la suite
de soupe,
je ne sais pas,
je n'ai pas fait de soupe
en longtemps.
Donc,
pensez sur les adapteurs
d'incompréhens,
ou les adapteurs de port.
Si, par exemple,
vous avez eu un service
qui était un service de travail
et qui était en train de
les écouter des messages
en arrivant à l'aventure
comme l'aventure de service
et le service de service
et la mQ, ou quelque chose.
Donc, votre application,
ce n'est pas en train
d'avoir l'application,
c'est en train de l'entraîner,
mais conceptuellement,
les messages arrivent.
Est-ce que c'est un adepteur
d'incompréhens, je pense ?
Oui,
c'est sur l'insécution,
et nous pouvons discuter
comment,
je veux dire,
l'insécution des mQs,
donc,
votre consommer de mQs
est sur l'insécution,
mais le public de mQs
est sur l'insécution,
c'est un exemple
où un mot de mQs,
une technologie est sur deux places.
Donc,
en revanche,
sur l'insécution.
Les exemples typiques
d'insécution,
les implementations,
c'est-à-dire,
dans l'architecture,
qui s'appelle
les adapteurs d'adaptants,
c'est,
par exemple,
les contrôles de restes,
les contrôles de soupe,
les consumers de mQs,
les consumers de mQs,
les applications de mQs,
les applications de mQs,
toutes ces sont les adapteurs de mQs,
et le point est
qu'ils endentent
par appeler
vos interfaces de service.
Donc,
si nous nous rappelons,
nous avons un service d'interface d'order,
qui a,
ce service d'order,
est le port d'incompré,
qui a les méthodes de créer l'order,
approver l'order et de s'accorder.
Nous pouvons avoir un contrôle d'application restée,
qui a des postes,
ou des méthodes,
et ça s'appelle
ces méthodes de service.
Nous pouvons avoir un mQ de mQ de rabat,
qui est,
d'une certaine façon,
recevoir un réquest
pour créer un ordre,
ou pour approver un ordre,
pour s'accorder un ordre.
Et ça s'appelle aussi
ce service d'interface.
Donc, votre logiciel de application,
ce service,
ne sait pas et ne cares pas
ce qu'on appelle ça.
Il a une seule responsabilité,
un travail,
qui fait ça
avec ce data d'incompré
qui ne donne pas de la technologie
qui a envoyé ce data d'incompré.
C'est ça, ou pas ?
Oui, exactement.

le service d'interface
n'a pas de connaissance
de qui le appelle,
donc il n'a pas de connaissance
de ce que l'on appelle
par un contrôle resté
ou un mQ de rabat,
consumer.
Il ne cares pas.
Et l'autre aspect
qu'il faut ajouter,
c'est que,
ensuite,
il devient facile
d'interchanger ces adapters.
Donc,
peut-être que la team initialement

avec les contrôle resté API,
et parce que tous les services micros
étaient directement appelés à l'un de l'autre,
et après,
ils ont décidé de migrer
à une éventuelle architecture
en train de créer
et ils ont décidé
de remplir
un whole bunch de contrôle resté API
par les contrôle resté API
par les consommateurs de rabat,
c'est très facile
de faire,
parce que tout ceci
est essentiellement un line.
Essentiellement.
Oui, parce que ça change
dans l'adaptateur
et puis,
en détenant votre registration IOC.
Donc, en regardant la registration IOC,
je veux expliquer la différence
entre l'impact
sur l'incompte
et l'outre-de-goût.
Donc,
sur l'outre-de-goût,
c'est exactement correct.
Initialement,
nous en avons réglé
que,
on dirait,
l'interface de la gate de la maison
est being implemented
avec
SAP Warehouse Gateway implementation.
Et quand on n'est plus en train
de utiliser SAP
ou d'utiliser quelque chose d'autre,
nous le répliquons.
Donc, en ce cas,
oui,
c'est un update en ligne
dans la registration IOC.
Mais pour l'insertion,
la partie que nous avons registrée
dans l'intérêt IOC,
est que l'interface d'interface
est being registered,
l'implementation est registrée
et l'interface d'interface
est l'interface d'interface.
Cette partie continue
de rester irrespective
de tout.
Maintenant,
comme vous êtes
en train de changer
de,
on dirait,
l'application REST
ou
de,
on dirait,
les consumers de la RABITMQ,
vous pouvez avoir une ligne
sur tout ce ou quelque chose
qui n'est pas
relative à
d'autres classes de services
qui sont simplement
en train de changer l'implementation.
Donc, oui,
c'est un petit impact.
Oui, ça me rend le sens.
Vous pensez à la RABITMQ,
donc une technologie
utilise beaucoup de mass transit,
qui est une abstraction
sur un message à cause.
Et
vous avez en fait fini
avec la classe consumer,
qui est,
je me suis souvent
mis en place l'application logic
là-bas,
mais je pense que
si on regarde
ce que nous parlons ici,
ce serait
le bon endroit
pour mettre,
c'est presque comme un contrôle,
je pense.
Mais puis,
peut-je,
je peux presque dire
que c'est mon hexagon
et la mass transit est
l'adapter et je peux juste...
Parce que c'est,
je pense que
l'un des choses que j'aime
de la consommation
dans la mass transit
ou
quelque chose,
ou même la mass transit

ou quelque chose,
c'est
que c'est toujours
une seule responsabilité.
Avec un contrôleur,
vous pouvez avoir
des postes,
comme vous l'avez mentionné,
des postes,
se délèrent
et il y a beaucoup de responsabilités.
Donc,
j'aime
de la technologie business
de ce genre.
Mais avec la mediator
ou la mass transit
de la consommation,
c'est un
méthode execute
ou un méthode de la consommation
par votre classe.
Donc, ça me semble
comme
que cette rédirection
à un service
est une
nécessaire
rédirection,
je pense.
Exactement.
Et
depuis que vous avez
envoyé ce sujet
dans la discussion,
je veux dire que
les alternatives
dans l'implementation
de ces portes d'income
et des portes d'income
de l'architecture Hexagon
nous ont donné la choice
où les deux décisions
sont fine.
Donc,
ce que certains développeurs
peuvent choisir
est
de continuer
de utiliser
des services d'application.
Un exemple
était le service d'ordre
où le développeur
a la surface,
a la implementation
et typiquement
cette surface
a plusieurs méthodes.
Donc, le service d'ordre
a, sur les deux,
trois ou cinq méthodes.
C'est un approche
que nous pouvons dire
que ce sont des portes d'income
de l'architecture Hexagon
parce que l'architecture Hexagon
a
beaucoup de méthodes
qu'il a donné.
La autre alternative
est les portes d'architecture Hexagon.
Un exemple commun
que peut-être familiar
est le usage de
mediateur.
Donc, cela signifie
qu'à l'aide d'une service d'ordre
avec ces trois méthodes
de l'ordre d'ordre,
d'ordre d'ordre approf,
nous devons plutôt
avoir
un ordre d'ordre
d'ordre approf,
d'ordre d'ordre approf,
d'ordre de l'ordre de l'ordre cancelé
et tous ces méthodes
ont un méthode de l'execution single.
Donc, nous serions
juste à la place de la place de l'aide d'ordre.
En ce cas,
la interface de service
n'existe plus.
Elles sont délicates.
Et puis,
votre adapteur de driver
comme le contrôle resté
ou le consumer de la tue de l'application
serait en train de
faire un mediateur
de l'aide d'ordre
et de passer
à un request de création d'ordre
ou un request d'ordre d'ordre
ou quelque chose comme ça
et il est exécuté
par le handler correspondant.
Oui, ça me rend le sens.
Je veux dire que je suis un grand fan
de la patine de contrôle.
Si on utilise un mediateur ou pas,
c'est juste le fait que tu as un classe
qui apporte la injection dépendante
et qui fait un truc
de l'execution.
Il n'a pas eu beaucoup de choses.
Donc, un principle de responsabilité très single.
Et aussi, le nom de classe
fait ce que ça dit sur le taux.
Donc, vous pouvez regarder le nom de classe
ou le nom de file.
Et vous savez exactement ce que c'est pour faire.
C'est comme
« GET ORDER »
ou « CREATE ORDER »
C'est très clair de ça.
Je l'aime beaucoup.
Donc, c'est parce que ça
fit dans cette architecture.
Oui, je suis un grand fan
de ça aussi.
Et effectivement, c'est l'approche
dont je préfère
et promouvoir.
Typiquement avec les équipes,
j'applique avec les services d'application
parce que c'est ce qu'ils sont
familiers avec
et c'est ce qu'ils sortent
de tout ce qu'ils ont déjà eu.
Mais ensuite,
je suis en train de changer
sur ce plus fine,
graine d'approche.
Et l'autre aspect
que j'aime aussi
dans ce plus fine,
graine d'approche
est que
il explique
essentiellement
les cas de utilisation
immédiatement
par les noms de file.
Et ça aussi
s'occupe d'un grand contribution
qui a été élevé
dans la architecture clean
parce que dans la architecture clean
Uncle Bob a essentiellement
pris l'architecture hexagonale.
Mais une décision importante
qu'il a faite sur le top
est, spécifiquement,
qu'il ne sera pas
d'application de services,
mais d'abord,
ces cas de utilisation
de handles.
Juste en regardant les diagrams,
comparé, comme vous l'avez dit,
la architecture clean
et l'architecture hexagonale
et l'architecture onion,
c'est-à-dire
des termes différents,
comme vous l'avez dit,
il y a des cas de utilisation
et des choses.
Je pense que
ce n'est pas une chose
qui confie les développeurs
parce que si nous regardons
ces diagrams,
on a des cercles
avec différents
layers sur l'arrivée.
Sur l'arrivée,
il s'agit de l'UIs,
database,
même des tests
et des choses.
Et
on parle de l'incombe
et de l'outgo.
Et je pense que les développeurs
sont utilisés
d'un flow de data
où vous avez un UIs
ou quelque chose qui s'appelle
des applications
et des logiques,
qui se sont ensuite
causées à la database,
donc peut-être
à la gauche ou à la droite,
où,
si vous regardez le diagramme,
la droite et la droite
sur l'UIs et le database
sont sur la même
layer au-delà,
sur l'au-delà.
Donc,
je pense que,
pour mon avis,
ce serait plus
de direction dépendance,
plutôt que de direction de flow.
Mais
c'est un bon moyen
que nous pouvons expliquer
comment ça
est,
je pense que c'est des versions
dépendant,
je pense,
comment ça devient un cycle.
Oui,
c'est un bon sujet.
Qu'est-ce que l'un des relations
des architectures?
Je dirais
la plus importante architecture
ici
et la contribution cruciale
était en fait l'architecture hexagonale.
Je vois tous ces
dévivations.
Donc,
la façon dont je vois
ces architectures hexagonales
est celle qui
a été
pour l'essentiel
le concept qu'on a
de l'application,
que l'on a
de l'extérieur
et que l'application
ne dépend pas
du monde au-delà de l'extérieur,
mais plutôt de la dépendance
est envers.
Donc,
ce qui est sur l'extérieur,
les adapteurs
qui communiquent
avec l'extérieur,
les adapteurs
dépendent sur les portes
et les portes ne dépendent pas
du adapteur.
Donc,
la dépendance est
envers
contre l'exagonale.
Maintenant,
comme je l'ai dit,
la façon dont l'exagon est envers
n'est pas
réellement pas tout.
Donc,
ce qui s'est passé
avec l'architecture d'onion
plutôt que
ce hexagon
a été répliqué par un cercle
et ils ont aussi
ajouté
un autre cercle
sur les adapteurs
et ont retiré le concept
de gauche et de droite.
Pour faire ça plus confusant.
Oui,
et c'est pourquoi
je préfère
toujours montrer aux équipes
le diagramme d'exagonal architecture.
Je trouve que
le plus clair
les onions d'architecture
et l'architecture de la clean
c'est très confusant
de voir
la présentation
et la base de données
sur le même
cercle.
Et
je pense que ce que j'aimerais dire
est ce que je vois peut-être
comme l'essence
de la différence entre elles.
Donc l'architecture de l'exagon
définit
ce qu'est le boundary essentiel
de la séparation
de notre application
est séparé par l'extérieur
par les portes
et les adapteurs
implementent le mécanisme
de communiquer avec l'extérieur.
C'est l'essence.
L'architecture de l'exagon
ne prescrit pas
les laissances
dans l'exagon.
Donc comment on structure
notre application
ne prescrit pas.
Donc, est-ce que nous allons
avoir un service ordre
ou on va avoir
ces commandes-handlers
qui ne sont pas prescrits.
On va être
en train de
jouer les structures de données
pour notre ordre
et avoir tout le logic
dans les services
ou on va utiliser
l'objectif orienté
pour programmer
et avoir une classe de l'ordre riche
avec des méthodes et d'encapsulation.
Ce n'est pas prescrits.
Mais
dans
architectures comme
la salle de l'architecture
ce sont prescrits.
Donc, la salle de l'architecture
prend l'architecture exagonale
comme base
mais ajoute
des restrictions additionnelles
sur le top.
Donc, comme je l'ai dit,
l'architecture exagonale
ne prenez pas
en train de utiliser
les services d'application
ou
ceux de l'exagérateur de l'exagérateur
ne prenez pas
la granularité de la porte
en train de l'exagérateur exagonal.
La salle de l'architecture
d'un grand nombre
a spécifiquement
a choisi les commandes-handlers

La autre partie
où il y avait une choisie spécifique
fait en
architecture cleaner
est la laiture
dans
l'exagérateur exagonal.
Donc, comme je l'ai dit,
dans l'architecture exagérateur exagonale
il ne faut pas dire
quelles sont vos laitures
comment
tu structures
ton exagérateur exagonal.
La structure cleaner
dit
ce que les laitures sont.
Les laitures sont
des cas de utilisation.
Par exemple,
créer un ordre d'exagérateur
approcher un ordre d'exagérateur
ou un cas de utilisation,
ce que vous appelez.
Et
une autre laiture d'entités.
Donc, il y a une laiture
avec des entités.
Peut-être que ce soit un ordre d'entité,
un produit d'entité.
Et plus tard,
ces entités seront des entités riches.
Donc, l'ordre
va avoir un constructeur.
Il va avoir des méthodes
qui encapsulent
ses accesses.
Le ordre peut avoir des méthodes
sur le même ordre.
Pour apporter
le ordre.
Le ordre sait
comment calculer
son prix.
Donc, la calculation ne sera pas
dans le service ou le service
sera dans l'entité.
Donc, n'oubliez pas
que tous ces sont
des décisions
additionnelles
qui sont faites
dans, pour dire,
la architecture.
Le autre aspect est
que, en termes de unité de testabilité,
seulement l'architecture hexagonale
est
le
minimum
de la requimité.
Donc, juste pour détenir,
si nous voulons
obtenir une séparation
des problèmes et de testabilité,
l'architecture hexagonale
est la fondation.
Nous pouvons plus
dans les dérivations essentielles
de l'architecture
de la requimité.
Ça ressemble à un
l'architecture hexagonale
qui vous donne beaucoup plus
de flexibilité
et est un peu moins restrictif,
surtout si nous utilisons
ces technologies,
comme on l'a parlé
sur le mediateur
et le mass-transit
et tout ça.
Il est bien que vous vous touchiez
sur la testabilité
aussi,
parce que
je pense que ça
s'apprécit vraiment,
parce que si
tout votre logiciel de application
ne sait pas les interfaces,
donc,
peut-on nous décrire
si vous vous déclenchez
une interface pour vos tests,
que ce mock
est juste un autre adapter ?
Oui.
Donc,
ce mock
ou le plus grand
word
test double,
parce que nous pouvons
utiliser
mocs,
nous pouvons utiliser
fakes ou stubs
ou
tout ça.
Il est

un adapter.
Donc, ça veut dire
que nous pouvons
avoir des réels adapters,
comme
avec le SAP implementation
ou la Microsoft Dynamics
implementation sales force
implementation,
tout ça,
nous pouvons dire
ou le base database
implementation avec l'entity framework,
implementations réelles,
et puis nous avons aussi
pour chaque porte,
nous avons un test double
implementation,
qui pourrait être
un mock ou un fake,
ou
un autre test double.
Vous trouvez que
plus recentement,
je vois
faire un mock
comme ce que j'ai trouvé,
et que
j'ai personnellement utilisé
comme docker et de vrais databases
et test containers
et tout ce genre de choses.
Vous pensez que les choses comme ça
en faisant Hexagonal architecture
moins
nécessaires ?
Je vais trouver le meilleur
de la façon de dire ça,
mais vous savez ce que je veux dire ?
Oui,
j'aime cette question
parce que j'ai spent
plusieurs mois
aussi en pensant sur ça,
et j'ai demandé
cette question beaucoup.
Donc,
pour le moment,
nous allons commencer
historiquement
et ensuite nous allons arriver
au présent.
À la fois
que l'Hexagonal architecture
était
essentiellement
concevée,
leur
la seule chose qui existait
était,
ok,
il y a des vrais databases.
Il n'y avait pas de concept
de docker à ce point.
Et à la fois que
ceci a été
fait,
il y avait des casins,
je me souviens de Alastor
dans un YouTube
en récourant
le cas de
travailler avec un équipe
où
les gens qui
ont le database
ont besoin de faire certaines
changements
et l'application
depuis qu'ils étaient directement
appelés à la base de database,
ils étaient bloqués
dans le développement
par la dépendance.
Donc,
ça était partie de la raison
d'introduire
l'interface.
Donc, ça c'est juste une histoire
juste de
pourquoi
aucun concept de test
d'avons
était introduit
tout à l'heure.
Mais ensuite,
nous venons
au prochain point
de
ok,
le docker
en général.
Donc,
la seule partie
de l'Hexagonal architecture
où
n'importe quelle forme de test doubles
est essentiellement
utilisée
est
seulement
sur l'outre-de-outre
port
de l'aérosse.
Donc,
ça ne veut pas
dans l'Hexagonal.
Donc, il n'y a pas de
overmoc.
Nous ne mockeons pas
chaque classe
qui existe.
Nous ne mockeons

les outre-de-outres.
C'est
une chose importante
pour
le note.
Ensuite, nous venons
à la prochaine question
qui est
maintenant
si on a
un docker
et nous permet
de nous

séparer
les databases
en
très vite.
Cela n'était pas
possible
dans le
dans le passé.
Ils ont aussi
maintenant
existé
les containers tests
pour que nous puissions
même
faire des tests isolés
sans les
sharedes
database.
Cela n'était pas possible
dans le passé.
Donc, ce qui
se passe maintenant
est
quand quelqu'un
est
utilisant les containers tests
qu'ils peuvent
obtenir
des tests
en plus vite
et
les tests
peuvent aussi être isolés.
En other words,
acheter les mêmes
caractéristiques
que nous pourrions acheter
si nous avons utilisé
un test double.
La seule différence
que je vois
est
que le test double
serait un ordre
de magnitude
plus vite
que le
être
purement en mémoire.
C'est la seule différence que je vois.
Donc, je pense que maintenant
c'est un peu
de la ligne bleue.
Je suis encore
personnellement
en currently
utilisant
et
quand je travaille avec
les meilleurs teams
recommandant
l'usage de
test doubles.
Mais
en regardant les containers tests,
c'est encore
de l'arrière gré
qui
j'aimerais explorer
plus tard.

je ne
n'ai pas
d'autre
stand
pour moi.
Je ne trouve pas
que l'idée
de l'architecture hexagone
de l'architecture hexagone.
Oui, je pense que
par le point de vue test
vous pouvez dire
que
si vous ne vous en utilisez pas
comme
les containers tests et de l'article docker
vous n'avez pas besoin
d'utiliser des interfaces
tout le temps.
Mais
tous les
autres benefits
comme l'ignorant les tests
tous les autres benefits
que nous avons déclarés
avant
comme
le play et les games
et les détails de la détail
cela
ça
ça
ça
ça
ça
et c'est
et c'est
spécialement si vous utilisez
comme
le Bisharp
ou
ou
ou tout
vous pouvez
interagir
et bouger
entre les interfaces
et les implementations
si facilement
ce n'est pas comme
c'est costant
et vous pouvez les créer très rapidement
ce n'est pas comme
c'est costant
beaucoup de travail
donc
oui
donc
les bénéfices que nous avons déclaré
avant
ça

c'est
c'est
même si vous ne vous en avez pas besoin
pour les tests
oui
et c'est
ce que je trouve
un argument

en termes
de
pourquoi
je préfère
vous savez
l'usage
des interfaces
première
tout le impact
sur les développeurs
les minds
qu'ils peuvent penser
sur les termes domaines
et
comme sans
penser
est-ce que
ce qu'est-ce que
ce sera
les procédures
est-ce que
ce sera l'entité
des frameworks
est-ce qu'un
bénéfice que je vois
ce qu'est le bénéfice conceptuel
le autre bénéfice que je vois
est
en termes de
plus tard
on va dire
optimiser
les performances database
donc même si
on ne va pas
poursuivre
des bases de données
on va toujours
rester
avec le framework
ou tout
que nous avons
je trouverai
que
et nous avons
des problèmes
que nous avons découvert
sur le database
peut-être que
quelque chose de clair est
un petit peu
quelque chose de comme ça
c'est
plus facile
si vous ouvrez
un file
qui est
l'adapteur
et il a tout le framework entité
code
c'est beaucoup plus facile
à lire
et penser
sur la performance database
vers ce que vous avez
à voir
des lignes de l'entité
des frameworks entiers
qui sont spread
tout au
logic business
est
un argument
maintenant
le premier
sur la swap de database
qui était
seen as a
whole pro
when hexagonal architecture
was conceived
however in practice
that's the one that I found
happens relatively rarely
though it may happen
but it's rare
so that's why I use it
as a small argument
but the one of separation
of concerns is a big argument
the other also
big argument
that I personally see
is when the ORM
when you have upgrades
in ORM
I remember a case
with entity framework
it happened several years ago
where entity framework
changed the way
it does the inheritance mechanisms
I can't remember
was it with discriminants
or
discriminant
I can't remember the word
what happened
but essentially
where a whole team was blocked
in upgrading their project
because it all had
entity framework dependencies
everywhere
all due to that reason
whereas here
when we model our application
separate from entity framework
we are
not worried about
restrictions of entity framework
nor about its changes
in the upgrades
so if entity framework does upgrade
only a small portion
only the adapter is affected
yeah and I guess
even when we talk about Docker
and stuff
and entity framework
and databases
we're talking about stuff that
can be spun up locally in Docker
but you've also got
outgoing dependencies
which any test you can't do
it could be a third party service
that you have no control over
it could be
even if you've got a microservice architecture
and locally
when you're wanting your test
you don't want to spin up
every single one of your services
all your services
in that case
just being able to model that out
actually it's quite useful
exactly
and that's the one
where we don't have a choice
in terms of
we don't have a choice to debate
or can we use the real thing
can we not
because that one has a very clear
impact on testability
now
Alistair Cockburn
again
in Hexmore architecture
it was simply
outgoing
driven ports
there was no
sub classification of them
later as I worked in practice
I see that certain things
are more internal
to the application
like database
it is owned
by let's say the monolith
for the microservice
and that's the one where I said
someone could make the argument
of possibly using test containers
because there's a very clear ownership
but there are certain other things
which are very distant to us
which are not owned by us
which are third party systems
and other microservices
where
there is no choice
but to abstract it away
simply because if we call
the real instances then
that would be essentially
going in the realm of end to end
slow tests
which is what
unfortunately teams are doing
who are not using Hexmore architecture
yeah, definitely, definitely
I'm aware that we're quickly running out of time
but there is one extra question
I wanted to ask
so using Hexagonal architecture
are there any common mistakes
that you see people make?
yes, so I would say
that the first problem
the biggest mistakes is that
teams are not even aware
of the existence of Hexmore architecture at all
and they continue
let's say working with the
traditional
layered architecture
and missing out on all that
separation of concerns
and
justability
now when teams
do start
using Hexagonal architecture
I would say
some challenges that I've observed
is in let's say
knowing you know
what are the ports
so I've had cases where
teams especially for the outgoing
ports side
is where I've seen issues
that let's say teams might be naming their interface
like their outgoing port as like
ERP or SAP
or even within that port
having
how should I say
JSON
or HCP statuses
whereby that outgoing port
is actually not abstracting away
the infrastructure at all
that is one example of a mistake
the other aspect
let's see on the incoming port
again if someone within their service classes
is passing around
HTTP
raw requests
or headers
or returning
HTTP status codes
you know having some presentation concerns
in their service
is another problem
or even having again logic
accidentally being split
you know instead of
centralising
the logic within
service classes that again
some of the logic starts leaking out
in the presentation
or essentially leaking out
business logic into adapters
is another mistake
that I've seen
I would say
those are some
core
challenges that I've seen
yeah I could pitch like
if someone has an outbound interface
and they write methods like
I don't know
get documents from Azure storage
or something like that
don't put the Azure
just say get a document
then
the incoming side
like we've spoken about mediator before
so one thing I see quite often
when people use mediator
is maybe the
mediator handler
is returning
a HTTP status code
which then gets returned by the controller
when actually it should be
returning an enum
with
a name that is relevant to
what that handler is doing
so I think it's just like avoiding
that coupling I guess
exactly so understanding that
anything that's done within the hexagon
and its ports
that it should all be in terms of
the main terminology
and not technology implementation
whereas the adapters
are supposed to
translations
so let's say
the
order controller
should be responsible
for understanding
the response
from a service method
or from mediator handler
and then converting that
into the appropriate
HTTP status
yeah that makes sense
makes sense
so as I say we are running out of time
but shall we do dev tips
before we report
yes
I will let you go first
okay great
so I do recommend for our listeners
take a look at
Alistair Cogburn's
hexagon architecture article
so it's
alistair.cogburn.us
slash hexagonal
dash architecture
ou vous pouvez juste google
search alistair.cogburn
hexagonal architecture
cela vous donnera
d'informations utiles
sur les aspects fondamentaux
de la architecture hexagonale
et vous pouvez aussi
regarder
des meilleurs meetups
aussi sur Youtube
pour apprendre plus
sur la architecture hexagonale
et je recommande
que peut-être que vous faites
un petit project GitHub
où vous faites
votre application typique
et puis vous essayez
de faire un hexagonal
architecture
et voir
comment cela fonctionne
pour vous
ça ressemble bien
et je peux inclure tout les notes
dans les notes de la show
donc
les listes si vous avez
les notes de la show
vous pouvez voir
ces notes
donc mon dev tip
ce n'est pas vraiment
relative mais
une chose
pour un client currently
qui est vraiment
essayé de s'occuper
est
ajouter plus et plus de observabilité
et je trouve que c'est un des choses
juste comme
des tests et de sécurité
beaucoup de gens
qui se délaient
et qui ont été mis à l'aide
et de l'observabilité
c'est comme
ce qui fait un différence
on a tendance à utiliser
Grafana
pour les dashboards et tout
mais c'est comme
quoi que vous utilisez
quoi que vous utilisez
juste
en enregistrant
comme vous avez écrit un code
en pensant
comment
comment la observabilité
de ce code ou de ce feature
si vous utilisez l'open telemetrie
vous faites surement
de mettre les traces properes
et de mettre les métriques
comme ce qui se passe
et en pensant
si un problème
s'occupe avec cette production de code
si je suis un soutien
si je regarde
ce que j'aimerais voir
dans Grafana
ou tout le tout
qui m'a aidé
à dénoncer ce problème
parce que c'est juste une des choses
qui s'est mis à l'aide
et c'est une importante chose
à penser
comme en pensant
sur la sécurité
alors que votre code de développement
pense aussi sur la observabilité
cool
donc
avant de nous rappeler
où est le meilleur place pour les listeners
pour vous atteindre
si vous avez des questions
ou vous voulez parler
de l'architecture hexagonale
donc je dirais
je vous recommande les listeners
pour me suivre
sur LinkedIn
et Twitter
il y aura aussi
des liens
sur le discord
depuis que j'ai aussi
l'optimum
discord communique
qui est où
il y a un canal
sur les cours et les bouts
que j'ai planifié
pour relier
including about
architecture hexagonale
donc c'est aussi un endroit
où les listeners
peuvent poser
des questions et idées
dont je peux
prendre en compte
comme je le fais dans un livre
sur l'architecture hexagonale
et
enfin
je recommande aussi
de rejoindre
la communauté de l'excellence de tech
qui est où
nous avons des meilleurs meetups
qui font des topics
comme
architecture hexagonale
architecture clean
domaines de design
développement de tests
etc
donc je recommande ça aussi
ça va bien
et comme ça
je vais inclut les liens
pour tous vos socials
et les choses
dans les notes de la show
et aussi
vous êtes maintenant
sur le discord podcast
aussi
donc
je vais vous ajouter
la roule de guest
pour que vous vouliez
se voir sur le top
avec les autres guests
donc
c'est facile de faire
ceci aussi
ça va bien
avec ça
juste un grand merci
pour votre show
c'était vraiment
très diverti
et j'ai hâte de voir
je suis hopé
que sans diagrams
avec un podcast
on n'a pas réussi
à
aider les listeners
à comprendre
tout ce genre de choses
oui, c'est certainement
j'ai trouvé
ça
pour être un
plaisir
une expérience incroyable
et j'espère que c'est
utile pour les listeners
juste pour obtenir une idée
ou ce que l'architecture Hexicon
est en train de faire
et j'espère que
c'est une motivation
pour
rechercher plus
sur ça
et lire plus
sur l'architecture Hexicon
et essayer de le faire plus tard
oui, c'est certainement
et juste pour les listeners
que sur le web podcast
chaque épisode
a un commentaire
au bottom
si vous voulez un commentaire
sur les épisodes
donc avec ça
c'est un grand merci
pour tous les listeners
et je vous remercie
que ce podcast est sponsorisé
par Everstack
qui est mon propre company
qui est en train de faire des
services de consultation et de software
pour plus d'informations
visite Everstack.com
et si vous aimez le podcast
s'il vous plait
me plaît le nom de la parole
sur les médias sociaux
je n'ai pas normalement
utilisé le hashtag
UnhandledException
et je peux être trouvé
sur Twitter
à Drakkan
qui est
D-R-A-C-A-N
et mes DMs sont éprouvus
et mon blog
DanClock.com
a des liens pour tous mes socials
aussi
et puis comme je l'ai mentionné
avant
tout le truc qu'on a parlé
aujourd'hui
sera lié dans les show notes
qui peuvent être trouvé
sur
UnhandledException podcast
.com