Vu que c'est le sujet de ma prochaine conférence, il va bien falloir que je lise cet article ...

Je pense qu'il y aurait des façons plus rigoureuses d'arriver au même résultat. Mais c'est à mon sens un usage raisonnablement intéressant des limites respectives de l'homme et de la machine pour garantir une architecture correcte.

Voici pour cet ingénieur les neuf critères d'évaluation d'un langage de programmation (pour peu qu'on arrive à dépasser la question de l'identité construite par le développeur sur son langage préféré)

Oh wow, l'article est vraiment passionant sur la façon dont les questions de choix de langage, de framework, d'architecture, sont avant tout des constructions identitaires.
La psychologie se cache décidément partout ...

L'article est intéressant, aussi bien par le concept de l'outil (qui titille en moi une envie de changer Structurizr) que dans sa forme (le style visuel de l'article est dingue)

Ca semble être un outil qui complète agréablement (et qui puisse même potentiellement redéfinir) mes outillages d'architecture

J'ai survolé l'article, mais il semble dire des choses vraiment intéressantes (j'aime en particulier l'idée de faire les bonnes choses plutôt que toutes les choses)

Bon, je vais faire de l'architecture dans une équipe avec un gros focus Python, donc j'ai bien l'impression que je vais devoir passer à PyStructurizr

Toujours d'accord avec ce genre de pamphlet. La complexité d'un système doit être une conséquence de l'intensité de son usage, et pas une manière d'affirmer son talent (ou d'agrandir son budget)

Un article clair expliquant bien que, si on déploie Kafka à l'échelle d'une application (comme bus de message interne), on fait sans doute une erreur, parce que Postgres est largement assez puissant pour émuler l'ensemble des fonctionnalités de Kafka.

Un catalogue d'antipatterns d'architecture

Un arbre de décision bien pratique pour s'y retrouver dans un sous-ensemble des produits Amazon.

Mais c'est un excellent modèle dites donc !

Un bon article sur les attributs de qualité d'un système logiciel

La réflexion sur le fait qu'écrire un logiciel soit plus proche de l'écriture d'un texte de loi que d'une discussion est très intéressante, et me fait évidement penser à mes sujets d'architecture

Un article très intéressant sur la nécessité d'avoir des cartes des systèmes informatiques qu'on étudie, et sur la différence entre la carte de référence et la carte de découverte.

"Un système logiciel est essentiellement un pari formalisé sur les changements que vous anticipez." C'est très juste

Tout le monde connaît (à défaut d'utiliser) ArchUnit. Konsist semble fournir une alternative orientée Kotlin, mais à priori utilisable aussi en Java.

J'aime beaucoup cette vision de l'architecture en tant que travail d'explication du système

Comment des architectes normalisent-ils le métier d'architecture logicielle ? Avec des schémas d'architecture, bien sûr !