La phrase est d'une justesse incroyable : le vrai défi de l'architecte, c'est bien de présenter les vrais challenges de l'application. C'est à mon avis pour ça qu'il faut plusieurs types de diagrammes différents.

Tous ces conseils sont parfaitement justes ... sauf lorsqu'ils sont impossibles (ce qui peut arriver)

C'est une vision vachement musclée des machines à états. Je suis par ailleurs impressionné par l'expressivité du Rust, qui permet de ne déclarer des méthodes que quand le type générique a une certaine valeur.

Je vais devoir créer un plugin Shaarli pour étendre l'export (pour y ajouter l'image et le permalink, notament). Souhaitez-moi bon courage, parce que le PHP, c'est pas ma fête.

J'aime beaucoup cette vision de la résilience applicative. Ca casse bien les guignols qui serinnent que "antifragile, c'est tellement bien"

Chouette article, qui fournit à mon avis une introduction sympa à la documentation vivante ...

Je voudrais pas faire mon grognon, mais quand je compare la doc de référence des templates entre FreeMarker et les templates go ... il n'y a pas photo

Oh j'adore cette idée : les diagrammes d'architecture peuvent porter directement le lien vers le monitoring. C'est très chouette !

En parcourant la doc de PlantUML à la recherche du LAYOUT utilisé par C4-PlantUML, je suis tombé sur

1. Un préprocessuer
2. Un système de macro
   Il faut que je relise tout ça, parce que ça a l'air fou

Et paf, le livre complet mis en lien dans l'article d'introduction aux cartes de Wardley

Un court mais bon article sur l'intérêt des ADR. Je reviendrai dessus prochainement, je pense

C'est très bien expliqué dans "agile architecture documentation". Et c'est la raison pour laquelle mes documents d'architecture ne font que reprendre les documents disponibles par ailleurs.

Si tu sais pas te mettre au télétravail, cette page (faite par un collègue) a quelques très bonnes ressources

Ca m'a l'air d'un ensemble d'articles d'une lecture particulièrement utile (en plus, le lien entre Sun Tsu et Simon Wardley ressemble à un sacré grand écart).

Oh mais c'est à peu près ma méthode de documentation d'architecture !

Une bonne présentation de pattern d'architecture. Bon, celui-ci est une vision assez raisonnable du microservice, en plus.

Une belle liste de ressources sur C4. Ca me donne envie d'essayer d'autres styles de rendu que celui de Ricardo

Si tu fais du graphe, cette page est un complément très intéressant à la doc officielle de Gremlin (qui est déja complète)

Un très chouette article différenciant correctement Event Sourcing et Change Data Capture. Ca aide bien à comprendre.

Si tu cherches des exemples de documents d'architecture, il y en a un paquet sur ce site.
Et bonus caché, comme il ya plusieurs formalismes, tu peux choisir celui qui t'intéresse le plus.