Cette police de caractère semble capable, grâce au pouvoir des ligatures, de créer des diagrammes simplement en écrivant le texte de ce qu'ils représentent. Le manuel est complètement dingue.
Un outil de diagram as text générant du SVG. Je ne m'y attendais pas trop ... Mais il va falloir tester ça. Qui sait, ce sera peut-être aussi bien que PlantUML
Il y a quelques règles intéressantes dans cet article. Mais elles me paraissent un peu trop basiques pour être utiles.
Je n'avais pas vu cet article qui explique bien l'intérêt de l'approche simple promue par le modèle C4. C'est le genre de retour qui me fait plaisir (sans doute parce que j'ai investi beaucoup de temps professionnel à monter en compétence sur ce sujet)
Une citation très intéressante : si vous réfléchissez correctement à votre architecture, vos diagrammes ne vous apprendront pas grand chose. Mais si vous n'y réfléchissez pas, vous ne penserez pas à produire des diagrammes qui vous sortiront des ennuis.
Evidement que cette citation m'interpèle
Dragon est une re formalisation des flowchart qui semble plutôt intéressante parce qu'elle systématise le bon chemin.
Très bons conseils sur l'architecture et la documentation qui doit aller avec (mais n'oubliez pas, les diagrammes ne donnent pas l'histoire du système)
Une librairie PlantUML qui supporte l'event storming, ce sera bien mieux que de le faire avec Miro !
Un très bon article expliquant les tenants et les aboutissants de Wardley to Go,Un DSL permettant de créer facilement. Des diagrammes de Warldley.
Encore un slide à ajouter dans ma présentation de mercredi prochain
Je n'ai lu que le début de la discussion, et je sais qu'il faut que je la lise en entier, mais rien que les trois premières réponses lues sont fascinantes
Je n'ai que rarement vu ou lu quoi que ce soit articulant aussi bien les cartes de Wardley, le DDD, les team topologies dans le but de livrer vite et bien. C'est un présentation incroyablement instructive.
Je vais garder cette citation dans un coin, parce que ça me semble une réflexion très pertinente sur ce qu'on choisit de mettre dans un diagramme ou pas.
Si vous voulez comparer différents outils de diagram as code, c'est un très bon site, qui montre à la fois les différences de grammaire, mais aussi les différences de grammaire. (D2 s'en sort pas mal du tout !)
Pour des raisons personnelles et historiques, je préfère nettement PlantUML. Mais cet article offre un contrepoint intéressant sur leurs qualités respectives
Retenez-moi, ou je code un exporteur PlantUML vers du HTML + JS avec cette librairie et un peu de positionnement libre ...
Le point de départ de beaucoup de mes idées de ces dernières années
ddocker run -it --rm -p 8080:8080 -v %CD%:/usr/local/structurizr structurizr/lite
Une critique valide, qui peut figurer en préambule de n'importe quelle documentation d'architecture
Un générateur de diagramme de gantt qui semble sortir du pur HTML. Ca m'a l'air mieux que TaskJuggler ou même que ce que fait PlantUML
Un plugin maven générant les diagrammes de classe au format PlantUML. Ca répond à un besoin très précis que j'ai exactement aujourd'hui
Pour quelqu'un comme moi qui préfère l'asciidoc et PlantUML, je ferais vraiment mieux d'utiliser Gitlab, non ?
Pour aller (beaucoup) plus loin que la création d'un diagramme de Gantt "simple", TaskJuggler est quand même bien plus puissant que PlantUML (et évidement, il y a une image Docker pour ça)
Décomposition architecturale et DDD peuvent évidement faire bon ménage, comme le montre cet article
Le concept est bon, il ne manque plus qu'une image Docker (parce que l'idée d'installer un outil de build F# juste pour lancer cet outil me paraît limite)
J'aime beaucoup cette métaphore, c'est vraiment pertinent dans le cadre de systèmes évoluant d'une façon beaucoup plus organique que ce qu'on croit.
PlantUML, c'est génial (et je le pense vraiment). mais comme en ce moment je fais un gros diagramme, la limite de taille de diagramme est "un peu courte". Heureusement, la page GitHub donne la variable à positionner.
Quand je vois ça, je me dis qu'ilograph est vraiment un chouette outil, qui mériterait que j'y jette un oeil.
Un ensemble de macros plantuml permettant, en n'utilisant rien d'autre que pumla et plantuml, de créer un ensemble de diagrammes cohérents. La principale limite est pour moi d'exprimer le modèle dans une syntaxe non extensible par du code
Une intégration complète de kroki dans asciidoctor. J'espère que ça ne va pas trop changer ce que j'ai l'habitude de faire avec asciidoctor-diagram ...
Maintenant que je sais que je peux mettre du HTML natif dans mes présentations Asciidoc, ce genre de choses redevient beaucoup plus facilement possible
Je crois qu'il va bien falloir que je comprenne comment marche escalidraw, parce que ça m'a l'air riche de possibilité (évidement, il faudrait que j'arrive à le brancher à Structurizr)
Ca ressemble furieusement au mode mind map de plantuml, mais peut-être en encore mieux
C'est pour éviter ces erreurs (entre autres) que je ne fais jamais de diagramme moi-même, et que je laisse toujours ça à PlantUML/Graphviz. Parce qu'avec ces outils-là, on voit vite quand le diagramme devient moche (et ça arrive vite).
Je vais changer un bout de code beaucoup trop complexe pour utiliser cet intéressant DSL
Il y a dans cet article deux très belles citations, et une vision intéressante des diagrammes d'architecture, malheureusement diminués par un usage incorrect des légendes.
Ca m'a l'air sacrément intéressant comme idée ...
Le saviez-vous, il y a une conférence annuelle sur les diagrammes. C'est meta (et donc c'est mal), mais c'est néanmoins intéressant.
Je l'avais vu passer il y a un bon moment, et je pense que ça va me servir demain ... (heureusement que j'y ai réfléchi ce week-end)
Un outil assez pratique pour générer un diagramme de classe depuis du code Java. Il faut juste ne pas oublier qu'ajouter un package n'ajoute pas les classes qui sont dedans (à cause du modèle de chargement de classes, évidement).
Wow.
C'est peu-être payant, mais c'est sérieusement bien animé !
J'aime beaucoup cette idée d'intégrer les équipes aux documentations d'architecture, à cause des impacts politiques évidents
Je suis d'accord avec le constat fait précisément dans ce tweet, même si j'ai tendance à désapprouver les raisons évoquées. A mon avis, il s'agit plus du fait qu'un architecte est fondamentalement un rôle transient.
Peut-être un complément intéressant à l'écosystème PlantUML, mais connaissant la complexité qu'il y a à manipuler GraphViz, je crains le truc pas vraiment fiable ...
Si par hasard la doc de PlantUML (déja archi-complète) ne vous suffit pas, vous pouvez aussi lire celle-ci
Un livre entier sur la construction de ces diagrammes, qui me paraissent des outils assez utiles de réflexion stratégique.
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.
Encore une autre approche de la modélisation de systèmes.
Je n'arrive pas à savoir si j'aime bien, ou pas. Il y a toutefois des règles de création de diagrammes assez chouettes.
J'aime beaucoup cette vision de la résilience applicative. Ca casse bien les guignols qui serinnent que "antifragile, c'est tellement bien"
Je suis assez d'accord.
Typiquement, je n'ai pas encore trouvé de bonnes façon de recenser les différents canaux utilisés dans un MOM par une application ... Et de les représenter correctement dans mes diagrammes.