Je regardais l’architecture de Dusk sous un mauvais angle

Je pensais que l’ancienne architecture de @Dusk avait seulement besoin d’être optimisée.

Mais mon perception était fausse.

J’ai compris que le problème ne venait pas simplement du moteur. Il venait du plan qui l’entourait.

L’architecture précédente de Dusk utilisait une infrastructure sur mesure adaptée à ses besoins. Mais à mesure que l’écosystème grandissait, les intégrations nécessitaient davantage de travail personnalisé, de temps et de coûts.

Ça m’a rappelé un pont à une seule voie. Tant que le trafic est faible, ça fonctionne bien. Mais quand il augmente, parfois le pont doit être repensé.

Ça m’a fait me demander : si l’ancienne architecture fonctionnait, pourquoi la refaire ?

La nouvelle conception sépare les responsabilités : DuskDS gère le règlement et la disponibilité des données, tandis que DuskVM et DuskEVM fournissent des environnements d’exécution.

Et là, tout s’est éclairé : bien sûr, l’objectif n’était pas seulement d’améliorer l’ancienne architecture. Il s’agissait de l’adapter à ce que Dusk était en train de devenir.

J’ai d’abord vu une mise à niveau comme un réglage du moteur. Maintenant, je vois une refonte du plan.

Un système peut dépasser le design qui l’a construit.

Les systèmes en croissance ont-ils besoin d’une nouvelle architecture, pas seulement de meilleures performances ?

$DUSK #dusk

Quand un système grandit, qu’est-ce qui compte le plus ?