Mais le 1, qui dit qu'il faut une base de code par application ? Non mais il fume quoi?
Le problème n'est pas le monorepo, mais le multirepo inconsistant. Si tu as 30 applications, qui ne fonctionnent ensemble qu'en version précise, c'est une application distribuée et surtout pas
des microservices. Le monorepo a l'avantage de gérer l'évolution parallèle des applications : c'est souhaitable mais pas toujours possible de gérer plusieurs versions d'API, pour éviter de devoir tout migrer d'un coup (syndrome du "monolithe distribué", aka l'enfer sur terre)
Et le 11, qui dit que les logs doivent être des événements ?
L'avantage des événements au sens DDD ou équivalent, ce sont des éléments auto-porteurs qui ne dépendent pas du contexte et sont des petits messages. Ils contiennent une date et des identifiants, ainsi on peut faire des pipelines de traitement en oubliant l'origine de l’événement (ELK, ...). Un événement n'a ainsi aucun sens d'être modifiable : l’immutabilité offre beaucoup d'avantage.
[^] # Re: Explication
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 3.
Le problème n'est pas le monorepo, mais le multirepo inconsistant. Si tu as 30 applications, qui ne fonctionnent ensemble qu'en version précise, c'est une application distribuée et surtout pas
des microservices. Le monorepo a l'avantage de gérer l'évolution parallèle des applications : c'est souhaitable mais pas toujours possible de gérer plusieurs versions d'API, pour éviter de devoir tout migrer d'un coup (syndrome du "monolithe distribué", aka l'enfer sur terre)
L'avantage des événements au sens DDD ou équivalent, ce sont des éléments auto-porteurs qui ne dépendent pas du contexte et sont des petits messages. Ils contiennent une date et des identifiants, ainsi on peut faire des pipelines de traitement en oubliant l'origine de l’événement (ELK, ...). Un événement n'a ainsi aucun sens d'être modifiable : l’immutabilité offre beaucoup d'avantage.
"La première sécurité est la liberté"